Move off rollup-plugin-ts#136
Conversation
|
For v1 addons (since merging ember-cli/ember-cli#10283) we have |
|
probably, yeah. I'll make the change once I can figure out how to get CI to a green state. Right now it looks like I need to first rip out the |
|
The failing test seems unrelated to |
|
That is different from what I saw locally! |
|
oh, and look at that, it's green! yay! |
|
Before merging the pull request, I think it'd be a good idea to see the suggested change in action. That is, check that the code change works on existing v2 addons (at least two---one with Glint and another without). The pull requests for those addons could serve as a migration guide. What do you think? On a related note, will there be an announcement from the Embroider team to v2 addon authors that they should migrate away from |
@ijlee2 Personally, I don't see that v2 addon authors, v1 addon authors, and app authors would have to adhere to whatever is in the blueprint. If rollup-plugin-ts is working for folks, then they shouldn't feel like they need to change anything. Also, we have tests that generate addons and ensure that they are buildable 🎉
This is typically the blueprint changelog, yeah? |
simonihmig
left a comment
There was a problem hiding this comment.
The changes look great to me!
However I was thinking to maybe try out the changes in some real-world addons, to make sure everything DX-wise works as expected...
|
I did one yesterday: https://github.com/universal-ember/ember-primitives/blob/main/ember-primitives/package.json#L17 |
|
Here are two more, created directly from this blueprint:
This is the only thing I noticed with the TS blueprint, which is causing issues (types don't build due to errors -- but that's a separate issue from this PR -- the minimum versions in the package.json are too low. I did see this time when generating these repos that we need to have the "no clear screen" flag turned on for rollup and tsc |
|
Looks like Glint doesn't have a way to not clear the screen in watch mode -- I'll open an issue over there |
Update the addon boilerplate to align with embroider-build/addon-blueprint#136.
| "lint:js:fix": "eslint . --fix",<% if (typescript) { %> | ||
| "lint:types": "glint",<% } %> | ||
| "start": "rollup --config --watch", | ||
| "lint:types": "glint", |
There was a problem hiding this comment.
Why does this sometimes use --build and other times not? Are you using --build here because it implies --declaration?
As we've discussed in the past, --build is for orchestrating composite multi-project builds by traversing references, and has nontrivial overhead in terms of the machinery it sets up. If you're going to use it, you should use it consistently for all glint/tsc commands, but in this case it doesn't seem like it should be necessary.
There was a problem hiding this comment.
Good callout, I missed that!
I tested this in my addon, and came up with the changes in this commit:
- remove
--build - remove all compilerOptions except for
declarationDir. The other don't seem to be needed AFAICT, maybe implied by-d? - added
-dto thebuild:typesscript. Having"declaration": truealone does not seem to work,-dis strictly needed for glint to output declaration files, is that right?
There was a problem hiding this comment.
The other don't seem to be needed AFAICT, maybe implied by -d?
They may be set to reasonable defaults in @tsconfig/ember
Having "declaration": true alone does not seem to work, -d is strictly needed for glint to output declaration files, is that right?
It's arguably a bug in Glint that we require you to run with --declaration to emit .d.ts files. I think the reason we landed there is that there's some hazy gray area in terms of what it means for us to match tsc's own behavior, since we effectively hard-code noEmit: true, which implies certain things about how other config like declarations behaves.
Regardless, you're correct that you have to use the --declaration/-d flag for the Glint CLI to emit .d.ts files today, even if we should potentially revisit that in Glint at some point.
Looking at that commit you linked, I think you also probably want -d in your start:types script so that that will update your .d.ts files as your sources change. Otherwise looks reasonable to me! 👍
| "scripts": {<% if (typescript) { %> | ||
| "build": "concurrently 'npm:build:*'", | ||
| "build:js": "rollup --config", | ||
| "build:types": "glint --build", <% } else { %> | ||
| "build": "rollup --config", <% } %> |
There was a problem hiding this comment.
What do you think of keeping concurrently for both TS and JS builds? that way we can just add the build:types in case of typescript
Just an idea
There was a problem hiding this comment.
idk, if we keep each convenience thing for TS in the JS version of the addon, we'd probably have a lot less conditionals all over the place.
Since this is blocking other work, how do you feel about discussing in another pr?
There was a problem hiding this comment.
don't think of any of my comments as a blocker 👍 they are only minor suggestions that are more helpful as DX for us than anything else
There was a problem hiding this comment.
Personally, i'm quite used to bending myself in to a pretzel so that consumers have a nice experience 🙃😅
| "start": "concurrently 'npm:start:*'", | ||
| "start:js": "rollup --config --watch --no-watch.clearScreen", | ||
| "start:types": "glint --build --watch",<% } else { %> | ||
| "start": "rollup --config --watch", <% } %> |
There was a problem hiding this comment.
same as above comment re: concurrently and only adding or removing the start:types based on the flag
| # npm/pnpm/yarn pack output | ||
| *.tgz |
There was a problem hiding this comment.
@NullVoxPopuli Can you explain to me how you had encountered the need to ignore *.tgz?
When I ran the publish --dry-run command, I didn't see any file with the .tgz extension so I feel like we wouldn't need lines 9-10.
There was a problem hiding this comment.
If you run pnpm pack (for example, to verify a package would publish as you expect), you get a tgz file in your addon directory - we don't want that comitted.
There was a problem hiding this comment.
Ah, ok. Thanks for providing more context.
| "start": "rollup --config --watch", | ||
| "lint:types": "glint", | ||
| "start": "concurrently 'npm:start:*'", | ||
| "start:js": "rollup --config --watch --no-watch.clearScreen", |
There was a problem hiding this comment.
I didn't encounter the need for --no-watch.clearScreen and would recommend keeping commands simple.
| "start:js": "rollup --config --watch --no-watch.clearScreen", | |
| "start:js": "rollup --config --watch", |
The above matches the command for the JavaScript case.
There was a problem hiding this comment.
Without this, both rollup and glint (tsc) fight for clearing the screen.
To prevent accidentally hiding issues, we need the screen to not clear on (re)build (which is what the flag does).
I have an issue for myself to investigate for the glint side of this: typed-ember/glint#597 (comment)
|
@NullVoxPopuli Nice work. In 4 addons (though none without Glint), I checked that we can remove |
Co-authored-by: Isaac Lee <16869656+ijlee2@users.noreply.github.com>
Co-authored-by: Isaac Lee <16869656+ijlee2@users.noreply.github.com>
Co-authored-by: Isaac Lee <16869656+ijlee2@users.noreply.github.com>
It's a team effort! I super appreciate the level of depth you all put in to reviewing this PR! |
| "scripts": { | ||
| "build": "rollup --config", | ||
| "scripts": {<% if (typescript) { %> | ||
| "build": "concurrently 'npm:build:*'", |
There was a problem hiding this comment.
suggestion (optional)
When using concurrently for build and start, we could add --names like we do for lint.
- "build": "concurrently 'npm:build:*'",
+ "build": "concurrently 'npm:build:*' --names 'build:'",# Before
[types] > ember-container-query@4.0.4 build:types
[types] > glint --build
[types]
[js]
[js] > ember-container-query@4.0.4 build:js
[js] > rollup --config
[js] # After
[build:types] > ember-container-query@4.0.4 build:types
[build:types] > glint --build
[build:types]
[build:js]
[build:js] > ember-container-query@4.0.4 build:js
[build:js] > rollup --config
[build:js] There was a problem hiding this comment.
I kinda like the more concise output here. I will concede to others tho, if that's what folks want
…ollup-plugin-ts Move off rollup-plugin-ts
…ollup-plugin-ts Move off rollup-plugin-ts
Resolves: #135, #112, and maybe #133
Because tsc/glint and rollup each have their own cleanup phase, we can't use reliably the same
distdirectory anymore. So, for type-declarations, I've chosen the creatively named "dist-types" for where the declarations will go and configured in the tsconfig.json to output the declarations there.We originally(?) had a setup similar to this, but had wanted to have type-declaration generation combined with the rollup build.
@rollup/plugin-typescriptandrollup-plugin-tsboth offer this, butrollup-plugin-tsdoes way too much, and has been causing us problems.@rollup/plugin-typescriptdoesn't integrate with Glint/gjs/gts, so that's not an option either. (See #135, and related links for more context).Additionally, the approach here, with manually specifying
extensionslooks annoying, but it's flexible, and I have an addon using gjs/gts with this approach already.