Switch to pnpm #348
Switch to pnpm #348
Conversation
NullVoxPopuli
force-pushed
the
switch-to-pnpm
branch
2 times, most recently
from
5a577cb
to
e5f4847
Compare
| "overrides": { | ||
| "@octokit/core": "^4.0.0" | ||
| }, | ||
| "overrides-notes": { |
There was a problem hiding this comment.
This is super nice. Is override-notes a baked-in pnpm thing or does it just ignore unknown keys?
There was a problem hiding this comment.
It ignores unknown keys - would be cool if this were standardized or something 🤔
| @@ -9,7 +9,7 @@ Compatibility | |||
|
|
|||
| * Ember.js v3.20 or above | |||
| * Ember CLI v3.20 or above | |||
| * Node.js v12 or above | |||
| * Node.js v14 or above | |||
There was a problem hiding this comment.
Just want to flag up: this is breaking! That's fine as long as it's intentional. 😅
There was a problem hiding this comment.
it is!
node 12 is EOL'd, and pnpm doesn't support it
|
got the once that lands, the |
This is due to a bunch of dependencies not providing it already.
The original Error:
ERR_PNPM_PEER_DEP_ISSUES Unmet peer dependencies
.
├─┬ @babel/cli
│ └── ✕ missing peer @babel/core@^7.0.0-0
├─┬ @babel/preset-typescript
│ ├── ✕ missing peer @babel/core@^7.0.0-0
│ └─┬ @babel/plugin-transform-typescript
│ ├── ✕ missing peer @babel/core@^7.0.0-0
│ ├─┬ @babel/helper-create-class-features-plugin
│ │ └── ✕ missing peer @babel/core@^7.0.0
│ └─┬ @babel/plugin-syntax-typescript
│ └── ✕ missing peer @babel/core@^7.0.0-0
├─┬ @ember/test-helpers
│ └─┬ ember-destroyable-polyfill
│ └─┬ ember-compatibility-helpers
│ └─┬ babel-plugin-debug-macros
│ └── ✕ missing peer @babel/core@^7.0.0-beta.42
├─┬ @glimmer/component
│ └─┬ ember-cli-typescript
│ └─┬ @babel/plugin-transform-typescript
│ └── ✕ missing peer @babel/core@^7.0.0-0
├─┬ ember-load-initializers
│ └─┬ ember-cli-typescript
│ ├─┬ @babel/plugin-proposal-class-properties
│ │ └── ✕ missing peer @babel/core@^7.0.0-0
│ └─┬ @babel/plugin-transform-typescript
│ └── ✕ missing peer @babel/core@^7.0.0-0
├─┬ ember-resolver
│ └─┬ babel-plugin-debug-macros
│ └── ✕ missing peer @babel/core@^7.0.0
├─┬ ember-source
│ ├─┬ @babel/plugin-transform-block-scoping
│ │ └── ✕ missing peer @babel/core@^7.0.0-0
│ └─┬ @babel/plugin-transform-object-assign
│ └── ✕ missing peer @babel/core@^7.0.0-0
└─┬ release-it
└─┬ @octokit/rest
└─┬ @octokit/plugin-paginate-rest
└── ✕ unmet peer @octokit/core@>=4: found 3.6.0 in @octokit/rest
Peer dependencies that should be installed:
@babel/core@">=7.0.0 <8.0.0"
release-it and release-it-lerna-changelog have incompatible peers.
The original error:
```
ERR_PNPM_PEER_DEP_ISSUES Unmet peer dependencies
.
└─┬ release-it
└─┬ @octokit/rest
└─┬ @octokit/plugin-paginate-rest
└── ✕ unmet peer @octokit/core@>=4: found 3.6.0 in @octokit/rest
hint: If you don't want pnpm to fail on peer dependency issues, add "strict-peer-dependencies=false" to an .npmrc file at the root of your project.
```
|
Tried rebasing this PR.
|
|
I would like to suggest that the future of |
|
Why is it considered de-stabilization to make it a v2 addon? |
NullVoxPopuli
force-pushed
the
switch-to-pnpm
branch
from
e5f4847
to
06ace34
Compare
|
The -import { camelize, capitalize } from '@ember/string';
+import { camelize, capitalize } from 'inflection'; |
I just mean what you said here:
|
|
ah yeah,
I'm making an assumption here -- so this could be wrong -- but I think maybe some of the uncertainty around v2 conversions is around keeping main/master releasable due to lack of time dedicated to maintain the projects -- imo, when it comes to v2 addon conversions, I don't think it's worth keeping main/master releasable. Keeping main/master releasable could resume post-v2 conversion, which generally would include the following breaking changes:
Keeping main/master releasable is greatly beneficial when projects don't have a lot of maintenance efforts behind them or if folks are busy, etc. But, I have the time and energy to push all the v2 addon conversions forward (one repo at a time), so if I were unblocked, the time of having unreleasable main/master would not be that long, and risk'd be low, and there would be only a single breaking change release with the above possible breaking changes. |
|
bah, inflection doesn't support dashes. nerdsniped myself dreamerslab/node.inflection#95 It's possible the maintainer does not want to support kebab case: dreamerslab/node.inflection#72 Made these tests: https://runkit.com/nullvoxpopuli/is-inflection-sufficient |
|
So I generally agree with @NullVoxPopuli on this one, I think there is overall benefit to upgrading this to v2 not just for Ember people but for people who are integrating Ember code that uses this package into other ecosystems. Before a v2 conversion this is just not possible As for breaking changes. I think we should convert this repo to use release-plan and block the merging of the release PR with a "request changes" until all the work is done. The only real breaking change is the requirement to use ember-auto-import@2 for this since as @NullVoxPopuli points out because after the v2 conversion this will no longer be dependent on node version 👍 If we're ok with this as a plan I'll open a PR to move to release-plan. How does that sound? |
This is part 1 of 5 in a series to convert
@ember/stringto a v2 addon in a less all at once way.Hopefully this process will demonstrate how others can take individual steps to migrating their addons to the v2 format (aka just a normal npm package)