Rename @wordpress/env to wp-env #21854
Conversation
|
Size Change: -18.3 kB (2%) Total Size: 817 kB
ℹ️ View Unchanged
|
| @@ -1,5 +1,5 @@ | |||
| { | |||
| "name": "@wordpress/env", | |||
| "name": "wp-env", | |||
There was a problem hiding this comment.
I'm assuming this is what Lerna looks at when publishing the package.
| @@ -1582,5 +1576,11 @@ | |||
| "slug": "packages-wordcount", | |||
| "markdown_source": "../packages/wordcount/README.md", | |||
| "parent": "packages" | |||
| }, | |||
| { | |||
| "title": "@wordpress/wp-env", | |||
There was a problem hiding this comment.
The tool that automatically generates this is incorrectly inserting the @wordpress/ prefix.
There was a problem hiding this comment.
Is it hard to fix? I tend to disagree with my previous comment to keep the package that is an alias outside of Gutenberg 😂
Pros:
Cons:
|
|
Wouldn’t it be easier to improve docs rather to go through this root that will deprecate the current package that folks already use and they might have installed globally? 😅 Aside: all packages are grouped under WordPress organization and this would introduce an exception. It probably wouldn’t be listed at https://www.npmjs.com/org/wordpress as well. |
You can always cherry-pick PR to wp/trunk branch and do the release there if the feature or bug fix is very important. We did it in the past several times 😃 |
#21809 does this. But I think there's value in renaming the package on top of that. There was some discussion in this Slack thread. I think the most compelling reason to do this is so that nobody else can register |
|
Can we maybe add another package outside of Gutenberg that aliases the package then? It’s too late for wp-scripts: https://www.npmjs.com/package/wp-scripts |
|
Is that possible? 🙂 |
Good question, in theory if you add a package that has @wordpress/env as a dependency the binary would get installed so it should work. I never tried it though 😜 |
| $ npm -g i wp-env | ||
| $ wp-env start |
There was a problem hiding this comment.
This could be switched back to npx wp-env start if/when the package is published. Is it worth doing that now or waiting?
noisysocks
force-pushed
the
update/rename-@wordpress/env-to-wp-env
branch
from
9e7752d to
c25755e
Compare
Rename the @wordpress/env package to wp-env so that the package name matches the binary name. This means users can run wp-env using `npx wp-env` without having to specify `-p @wordpress/env` which is often forgotten.
noisysocks
force-pushed
the
update/rename-@wordpress/env-to-wp-env
branch
from
c25755e to
002307b
Compare
noisysocks
requested review from
ajitbohra,
chrisvanpatten,
epiqueras,
karmatosed,
mapk,
mkaz,
noahtallen and
youknowriad
as code owners
|
Travis CI is now happy with this PR! I've marked it as ready for review. My preference is to rename Creating a new
What do you think @epiqueras? |
|
Can you explain why you want to rename the package? Is it because of I don't find the following to be the bad I personally like the consistency across our packages. Another possibility is |
|
I'm not a big fan of changing the package name -- I think it could (?) create more issues than it solves. We've already managed to get a lot of folks onboard with this tool, and I still get notified about comments on the original announcement post every week. So I mostly worry that this change will unnecessarily confuse everyone who has already gotten on board. I guess I don't see the benefits of a rename as being that good for users. For example:
I feel like the con of confusion is the main thing affecting users. I don't think the other items have a big affect on them. |
|
sorry, accidentally clicked the close button instead of the comment button 😅 😅 |
|
Thanks for the thoughts! I agree with the concerns raised. I'll explore if we can rename the binary to If that isn't feasible, I'll do nothing and |
Renames the
@wordpress/envpackage towp-envso that the package name matches the binary name. This means users can runwp-envusingnpx wp-envwithout having to specify-p @wordpress/envwhich is often forgotten.If this PR is merged then the next steps are to:
wp-envis added to the npm registry.npm deprecateon@wordpress/envwith a deprecation message that instructs users to usenpm install wp-envinstead.An alternative approach here would be to move
wp-envinto its own GitHub repository and out of the Lerna monorepo.