Set up release-it for publishing #1536
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chriskrycho
force-pushed
the
release-it-config
branch
3 times, most recently
from
b50dca4 to
dfdf102
Compare
|
The last thing here is to tweak the |
- Map our GitHub labels to our CHANGELOG conventions. - Set up Git, GitHub, and lerna-changelog release-it config.
Arrays need type declarations if they don't start with values!
Technically `typeRoots` *works*, but we don't generally want people doing that, and our tsconfig files get used as references. `paths` does the same thing in a way that *does* match how we want people to work, at least until such a time as we're in a more normal module resolution.
This allows us to correctly interop with the updated version of `got` we had to pull in to get our types checking correctly, which was also required because we use it directly *and* `release-it` uses it under the hood, so we had to get to a usable resolution.
Unlike a couple commits back, where I removed something because we want to avoid others copying it, here we end up *needing* to add it because there is not presently a story for how to handle `@types` declarations which are in the position `console-ui` is currently: - The consuming app/library is using `Node16` resolution, but does not have `"type": "module"` set, so TS interprets any unspecified module as being CJS. - The `@types` package itself depends on *another* package which is set to operate as ESM. Here, `console-ui`'s types point to `inquirer`'s types, which are set as ESM. In this situation, the direct dependency gets interpreted as CJS, and this produces an error, because it is CJS using `import` statements and TS complains that since it will be run as `require()` in CJS, you should switch to using dynamic import. But: it's a `.d.ts` file! We *cannot* use dynamic import there! Net, there is no current workaround for this that I have found; I have raised it in the TS Discord, and we will want to come up with a better solution (in this case: probably just by converting `console-ui` to publish a dual-package mode package *and* publish its own types). And in the meantime... we will ship this with `skipLibCheck`. :sigh:
We had missed some of the changes which affected how the two packages related; bumping both gets us back to passing. In a future (separate!) PR we can also bump ember-cli-babel to dodge a lot of these warnings, and others can also take us to using ember-source v4.
chriskrycho
force-pushed
the
release-it-config
branch
from
d5e7e5c to
ecc2b4c
Compare
At this point several of them *fail*, but that's progress.
5443048 introduced this to all the other configs, but it needs to be in the app fixture as well so that the same issue flagged up there does not blow up during the Ember build.
|
Looks good! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I never want to do the chore I did this morning for 5.2.0 again! 😂