-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Simon Ihmig <[email protected]>
Co-authored-by: Simon Ihmig <[email protected]>
"lint": "concurrently 'npm:lint:*(!fix)' --names 'lint:'", | ||
"lint:fix": "concurrently 'npm:lint:*:fix' --names 'fix:'", | ||
"lint:hbs": "ember-template-lint . --no-error-on-unmatched-pattern", | ||
"lint:js": "eslint . --cache", | ||
"lint:hbs:fix": "ember-template-lint . --fix --no-error-on-unmatched-pattern", | ||
"lint:js:fix": "eslint . --fix",<% if (typescript) { %> | ||
"lint:types": "glint",<% } %> | ||
"start": "rollup --config --watch", | ||
"lint:types": "glint", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
-d
to thebuild:types
script. Having"declaration": true
alone does not seem to work,-d
is strictly needed for glint to output declaration files, is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a minor suggestion 😂
files/__addonLocation__/package.json
Outdated
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, i'm quite used to bending myself in to a pretzel so that consumers have a nice experience 🙃😅
files/__addonLocation__/package.json
Outdated
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, thanks.
@NullVoxPopuli Nice work. In 4 addons (though none without Glint), I checked that we can remove |
Co-authored-by: Isaac Lee <[email protected]>
Co-authored-by: Isaac Lee <[email protected]>
Co-authored-by: Isaac Lee <[email protected]>
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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] > [email protected] build:types
[types] > glint --build
[types]
[js]
[js] > [email protected] build:js
[js] > rollup --config
[js]
# After
[build:types] > [email protected] build:types
[build:types] > glint --build
[build:types]
[build:js]
[build:js] > [email protected] build:js
[build:js] > rollup --config
[build:js]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kinda like the more concise output here. I will concede to others tho, if that's what folks want
Resolves: #135, #112, and maybe #133
Because tsc/glint and rollup each have their own cleanup phase, we can't use reliably the same
dist
directory 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-typescript
androllup-plugin-ts
both offer this, butrollup-plugin-ts
does way too much, and has been causing us problems.@rollup/plugin-typescript
doesn'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
extensions
looks annoying, but it's flexible, and I have an addon using gjs/gts with this approach already.