Skip to content
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

Merged
merged 15 commits into from
Jul 5, 2023
Merged

Move off rollup-plugin-ts #136

merged 15 commits into from
Jul 5, 2023

Conversation

NullVoxPopuli
Copy link
Collaborator

@NullVoxPopuli NullVoxPopuli commented Jul 3, 2023

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 and rollup-plugin-ts both offer this, but rollup-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.

@NullVoxPopuli NullVoxPopuli added the bug Something isn't working label Jul 3, 2023
@simonihmig
Copy link
Collaborator

For v1 addons (since merging ember-cli/ember-cli#10283) we have dist (used by Ember CLI, not published) and declarations for the types. Should we align to this here?

@NullVoxPopuli
Copy link
Collaborator Author

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 @types/* packages

@simonihmig
Copy link
Collaborator

The failing test seems unrelated to @types AFAICT, and quite close to passing though?

@NullVoxPopuli
Copy link
Collaborator Author

That is different from what I saw locally!
That is quite exciting.
Also, at some point, I should figure out how to get CI / local not able to be different

@NullVoxPopuli NullVoxPopuli marked this pull request as ready for review July 3, 2023 17:14
@NullVoxPopuli
Copy link
Collaborator Author

oh, and look at that, it's green! yay!

@ijlee2
Copy link
Contributor

ijlee2 commented Jul 3, 2023

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 rollup-plugin-ts soon?

@NullVoxPopuli
Copy link
Collaborator Author

that they should migrate away

@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 🎉

announcement from the Embroider team to v2 addon authors

This is typically the blueprint changelog, yeah?

files/__addonLocation__/.eslintignore Outdated Show resolved Hide resolved
files/__addonLocation__/.prettierignore Outdated Show resolved Hide resolved
Copy link
Collaborator

@simonihmig simonihmig left a 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...

@NullVoxPopuli
Copy link
Collaborator Author

I did one yesterday: https://github.com/universal-ember/ember-primitives/blob/main/ember-primitives/package.json#L17
Tho, still using dist-types instead of declarations

@NullVoxPopuli
Copy link
Collaborator Author

Here are two more, created directly from this blueprint:

❯ EMBER_CLI_PNPM=true npx ember-cli@beta addon no-rollup-plugin-ts-js --pnpm --addon-only -b ../OpenSource/emberjs/addon-blueprint/


❯ EMBER_CLI_PNPM=true npx ember-cli@beta addon no-rollup-plugin-ts-ts --pnpm --addon-only -b ../OpenSource/emberjs/addon-blueprint/ --typescript

This is the only thing I noticed with the TS blueprint,

.
└─┬ @glint/environment-ember-loose 1.0.2
  ├── ✕ unmet peer @types/ember__array@^4.0.2: found 4.0.0
  ├── ✕ unmet peer @types/ember__component@^4.0.10: found 4.0.0
  ├── ✕ unmet peer @types/ember__controller@^4.0.2: found 4.0.0
  ├── ✕ unmet peer @types/ember__object@^4.0.4: found 4.0.0
  └── ✕ unmet peer @types/ember__routing@^4.0.11: found 4.0.0

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

@NullVoxPopuli
Copy link
Collaborator Author

NullVoxPopuli commented Jul 4, 2023

Looks like Glint doesn't have a way to not clear the screen in watch mode -- I'll open an issue over there

typed-ember/glint#597

"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",
Copy link
Contributor

@dfreeman dfreeman Jul 5, 2023

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.

Copy link
Collaborator

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 the build:types script. Having "declaration": true alone does not seem to work, -d is strictly needed for glint to output declaration files, is that right?

Copy link
Contributor

@dfreeman dfreeman Jul 5, 2023

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! 👍

Copy link
Member

@mansona mansona left a 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 😂

Comment on lines 16 to 20
"scripts": {<% if (typescript) { %>
"build": "concurrently 'npm:build:*'",
"build:js": "rollup --config",
"build:types": "glint --build", <% } else { %>
"build": "rollup --config", <% } %>
Copy link
Member

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

Copy link
Collaborator Author

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?

Copy link
Member

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

Copy link
Collaborator Author

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 🙃😅

Comment on lines 28 to 31
"start": "concurrently 'npm:start:*'",
"start:js": "rollup --config --watch --no-watch.clearScreen",
"start:types": "glint --build --watch",<% } else { %>
"start": "rollup --config --watch", <% } %>
Copy link
Member

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

Comment on lines +9 to +10
# npm/pnpm/yarn pack output
*.tgz
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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",
Copy link
Contributor

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.

Suggested change
"start:js": "rollup --config --watch --no-watch.clearScreen",
"start:js": "rollup --config --watch",

The above matches the command for the JavaScript case.

Copy link
Collaborator Author

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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, thanks.

@ijlee2
Copy link
Contributor

ijlee2 commented Jul 5, 2023

@NullVoxPopuli Nice work. In 4 addons (though none without Glint), I checked that we can remove rollup-plugin-ts as suggested by this PR:

@NullVoxPopuli
Copy link
Collaborator Author

Nice work.

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:*'",
Copy link
Contributor

@ijlee2 ijlee2 Jul 5, 2023

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] 

Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TypeScript: let's discuss options, rollup-plugin-ts isn't working for us (as in: it's too much trouble)
5 participants