Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Rebuild not working with embroider (translation file changes will be ignored)
See original GitHub issueWhen 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
- Ember Version: 3.25.2
- Ember CLI Version: 3.25.2
- Ember Intl Version: 5.6.2
- Embroider: 0.37.0
- Node Version: 14.15.4
- OS: Windows x64 / Linux
Steps to Reproduce
npm install -g ember-cliember new test-appnpm i @embroider/core @embroider/compat @embroider/webpack- edit
ember-cli-build.js(specified in Readme.md) ember install ember-intl+ required file changes (see ember-intl quickstart)ember s- modify a translation file
Workaround
Set environment variable EMBROIDER_REBUILD_ADDONS=ember-intl
_Originally posted by @ef4 in https://github.com/embroider-build/embroider/issues/718#issuecomment-796914941_
It looks like ember-intl considers your translations part of itself (they live inside it’s own module namespace instead of the app’s).
Try setting the environment variable
EMBROIDER_REBUILD_ADDONS=ember-intl. That will probably work around this problem.ember-intl should consider refactoring so that translations stay in the app’s module namespace.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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
treeForAppin 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…”.
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?