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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
When generating a new app with --embroider use all optimisation flags #10370
Conversation
I'm a big fan. I would be pretty annoyed if this were an additional RFC. |
@NullVoxPopuli I don't think it would be annoying for this to be an RFC, I'm happy to go through that process if we think it warrants it 馃憤 I actually started writing this as an RFC first but then thought I would chance it as a PR first 馃槀 |
I don't think this needs an RFC. It is for new projects and as you say we would want them to start optimized. Anybody upgrading with the |
staticHelpers: true, | ||
staticModifiers: true, | ||
staticComponents: true, | ||
staticEmberSource: true, | ||
skipBabel: [ |
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.
in my ember-cli-build, I also have these:
// ember-inspector does not work with this flag
// staticEmberSource: true,
splitControllers: true,
splitRouteClasses: true,
packagerOptions: {
webpackConfig: {
// highest fidelity sourcemaps at the cost of speed
devtool: 'source-map'
}
}
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.
Hmm, if ember-inspector does not work with that flag, I am less sure about recommending it be on by default, even with the --embroider
flag
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.
well, its a very new flag, and still opt in.
all the other options are about preventing userland code from regressing to be non-vite compatible (fully static)
staticEmberSource is kind of along those same lines (e.g.: "make sure you don't use the private require APIs!"),
but small progress is still progress, and I think this PR is good progress. Because there is no worse feeling than "trying the new thing", only to find out that "you weren't good enough", because the static flags weren't enabled by default.
in the afternoon RFC meeting today, we talked about a strategy for fixing the inspector in the long term for future ember-source changes (similar to what we do for supporting ember-data), and I really like that approach.
0cc7299
to
a781924
Compare
345f9e4
to
4c21bfa
Compare
I converted this PR to draft because I have a WIP commit on the end to see if it fixes issues with embroider on CI. If it does I will go through and do a release of embroider and update this PR so it's ready to merge 馃憤 |
3af639e
to
db7bbb5
Compare
db7bbb5
to
1052c73
Compare
Firstly I don't know if this sort of change needs an RFC 馃 let me know if you think it does 馃憤Edit: we agreed that this wasn't RFC material 馃憤My reasoning for this change is that we are at the point now that when someone generates a new app with
--embroider
it's reasonable for them to have all the optimisations turned on by default and for them to turn them off as needs be. This will prevent people from staring with a new Embroider app and adding code that can't be optimised accidentally rather than actually consciously opting in/out of certain behaviours