Closed Krzyrok closed 10 months ago
Hmm, I've made some investigation and tried many things. I copied most of the config from one addon (which does not produce additional files) to another addon (which produces additional files - let's call it addonX
). Nothing helped.
But removing diretory app
from addonX
helped! Even if this directory is empty - duplicated files are generated. It has to be removed completely!
But we have some addons which have app
directory and they don't produce additional files. So I tried copy dependencies (NOT devDependencies) from correctly working addon to not working addon - but this didn't help.
Any clue? I don't see any pattern between addons.
@Krzyrok so sorry you're running into this! If possible, reproductions of this issue would help us chase it down. If you can provide an addon which does, and an addon which does not, produce this problem, we should be able to figure it out. Without that, it's unlikely we'll be able to fix it, since none of us have seen it.
One thing to check: are there existing .js
files in app
? See in particular the notes under Account for addon build pipeline changes in the docs—that's the only possibly-related factor I can think of. 🤔
I cannot provide these addons unfortunately.
According to your question - in app
's directory of addon we have only JS files (we don't have TS at all in this addon): components, helpers, initializers, instance-initializers, mixins, services, styles, templates.
Most of them have single line with reexport: export { default } from "addonX/components/..."
)
In app
's directory of main repository we have both - JS and TS files. But we override only one file in initializers
and one in mixins
directories (every file has JS extension).
I'm closing this as outdated and not actionable—both because we were never able to get to a clear reproduction, and because we now recommend that people switch to using ember-cli-babel
for apps (as documented here) and the rollup plugin configured as part of the v2 add-on build for add-ons, in conjunction with running glint
or tsc
directly on their projects.
Reading back through it, it's very likely this was a function of the switchover to using Babel for the entire “transpilation” step rather than pipelining TS and then Babel.
ember -v
ember-cli: 3.9.0 node: 10.13.0 os: linux x64 (Debian GNU/Linux 9.6 (stretch))
tsc -v
Version 3.4.3
ember-cli-typescript
andember-cli-typescript-blueprints
ember-cli-typescript-blueprints@2.0.0 ember-cli-typescript@2.0.1
tsconfig.json
andtslint.json
My tsconfig.json
My tslint.json
My tslint.json stored in addon
Reproduction Case
Sorry for that but I don't know how can I prepare reproduction steps/environment - bug occurs only in combination of used addons (developed by my team) so probably there is a reason - some conflict between ember-cli-typescript in version 2.0.1 and addon configuration. But I don't have any idea where to look and what can I test - so maybe some clue (where to look)?
Description:
I've upgraded ember-cli-typescript (and many other packages - e.g. typescript) to the newest version (and I used instructions from https://typed-ember.github.io/ember-cli-typescript/docs/upgrade-notes).
Everything seems to work. But after this upgrade, I have 3 instances of every generated JS file (transpiled from TS). Original JS files have single instances. What I mean: I heave a file [our-repo-name]/[my-file].ts. I've disabled source maps in babel (ember-cli-build) because it caused triple consumption time of rebuild (but this is NVM). And what now I see in chrome dev tools: 1) assets/[our-repo-name]/[our-addon1-repo-name]/tests/[my-file].js 2) assets/[our-repo-name]/[our-addon4-repo-name]/tests/[my-file].js 3) assets/[our-repo-name]/[my-file].js
My [addon1] and [addon4] don't use typescript and ember-cli-typescript at all (but another addons use - and they use TS@1.5.0, can it be a reason?).
The final bundle ([my-main-repo-name].js in dist) have triple definitions of these TS files and two times bigger size :/
If I revert only ember-cli-typescript (in main repo) to version 1.5.0, bundle is generated correctly (and one file definition is generated instead 3).
Now about that bug. What did you expect to see?
I expect normal bundle size - with single file definition generated per TS file.
What happened instead?
There are 3 file definitions per one TS file in the final bundle - bundle size is 2-3 times bigger.