Closed mkszepp closed 6 months ago
Embroider isn't officially supported.
Someone would need to port the addon's use of treeForAddon
to treeForApp
and change how the translations are loaded into the app to read from the app namespace by introducing a new loading strategy.
Embroider isn't officially supported.
Embroider the build tool isn't yet, but embroider the addon format is, and we're talking about addon behavior here. So it would be good to collaborate on a plan for how ember-intl can conform to that spec, or what extensions to the spec will be required before it can switch over.
Someone would need to port the addon's use of treeForAddon to treeForApp.
When somebody chooses to spend time on this issue, I would suggest against that approach. I don't actually know if it solves the rebuild problem, and treeForApp
itself is really a backward-compatibility feature that Ember is starting to move away from. Letting every library copy code directly into your app leads to a lot of hard-to-understand behavior, both for humans and for compilers.
Embroider the build tool isn't yet, but embroider the addon format is
I was referring to ember-intl not officially supporting it
treeForApp itself is really a backward-compatibility feature that Ember is starting to move away from.
I've been inactive in the Ember community, first time hearing of this. Seems like a significant change in direction for addons.
To be clear, it's not imminent. I don't think anybody needs to rush into doing anything, and no support is going to get dropped any time soon.
But taking the holistic view of recent RFCs like strict mode templates plus the embroider one linked above, it's pretty clear to me that new feature development is avoiding the runtime resolver, and that's what motivates treeForApp
in the first place.
I'm totally supportive of addon authors taking a wait-and-see approach until they get clear enough guidance. I only brought up the future compatibility concerns in the context of "if you were going to rewrite anyway..".
https://github.com/ember-cli/ember-cli/pull/9495 is going to bring embroider into ember-cli and then ~6 weeks out it'll hit stable. We'll want to come up with a strategy around this soon.
would it make sense to provide an unplugin for intl for the build stuff? that way ember-intl is then mostly the service, helper, and then maintains the unplugin for folks to put in their webpack/vite/etc configs?
This plugin should work https://github.com/lifeart/demo-ember-vite/blob/master/plugins/i18n-loader.ts, it's generates translation files on the fly as virtual module.
Closing this issue, as I don't see a rebuild issue in docs/my-app
and there isn't a reproduction repo in the original message. It's possible that the error had occurred under different assumptions back in 2021.
confirm that works now without EMBROIDER_REBUILD_ADDONS=ember-intl
maybe refacoring in embroider has resolved
When i add/edit a translation the rebuild with embroider is not working. There is always necessary to stop an restart
ember s
.Original issue: https://github.com/embroider-build/embroider/issues/718
Environment
Steps to Reproduce
npm install -g ember-cli
ember new test-app
npm i @embroider/core @embroider/compat @embroider/webpack
ember-cli-build.js
(specified in Readme.md)ember install ember-intl
+ required file changes (see ember-intl quickstart)ember s
Workaround
Set environment variable
EMBROIDER_REBUILD_ADDONS=ember-intl
Originally posted by @ef4 in https://github.com/embroider-build/embroider/issues/718#issuecomment-796914941