-
Notifications
You must be signed in to change notification settings - Fork 99
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
Inconsistent builds with addons having files with same names #724
Comments
This behavour may be related to ember-cli/ember-ajax#428 |
|
@chriskrycho 2 - no, 1 - updated. |
our production case: yarn workspaces: |
if it's hard to get fails:
|
// broken case ts input // lib\side-models\addon\models\meta-model.ts
import DS from 'ember-data';
export default class MetaModel extends DS.Model.extend({
name: 'addon-meta-model'
}) {
// normal class body definition here
}
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
declare module 'ember-data/types/registries/model' {
export default interface ModelRegistry {
'meta-model': MetaModel;
}
}
// app\models\base-model.ts
import MetaModel from 'side-models/models/meta-model';
export default class BaseModel extends MetaModel.extend({
baseName: 'baseModel'
}) {
// normal class body definition here
}
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
declare module 'ember-data/types/registries/model' {
export default interface ModelRegistry {
'base-model': BaseModel;
}
}
// app\models\meta-model.ts
import BaseModel from './base-model';
import { computed } from "@ember/object";
export default class MetaModel extends BaseModel.extend({
fullName: computed('name', 'baseName', function(){
return this.name + '/' + this.baseName;
})
}) {
// normal class body definition here
}
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
declare module 'ember-data/types/registries/model' {
export default interface ModelRegistry {
'metaModel': MetaModel;
}
}
// broken case js output ;define("side-models/models/meta-model", ["exports", "ember-data"], function (_exports, _emberData) {
"use strict";
Object.defineProperty(_exports, "__esModule", {
value: true
});
_exports.default = void 0;
class MetaModel extends _emberData.default.Model.extend({
name: 'addon-meta-model'
}) {} // normal class body definition here
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
_exports.default = MetaModel;
});
;define("ts-app/models/base-model", ["exports", "side-models/models/meta-model"], function (_exports, _metaModel) {
"use strict";
Object.defineProperty(_exports, "__esModule", {
value: true
});
_exports.default = void 0;
class BaseModel extends _metaModel.default.extend({
baseName: 'baseModel'
}) {} // normal class body definition here
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
_exports.default = BaseModel;
});
;define("ts-app/models/meta-model", ["exports", "side-models/models/meta-model"], function (_exports, _metaModel) {
"use strict";
Object.defineProperty(_exports, "__esModule", {
value: true
});
Object.defineProperty(_exports, "default", {
enumerable: true,
get: function () {
return _metaModel.default;
}
});
}); // valud case js output ;define("side-models/models/meta-model", ["exports", "ember-data"], function (_exports, _emberData) {
"use strict";
Object.defineProperty(_exports, "__esModule", {
value: true
});
_exports.default = void 0;
class MetaModel extends _emberData.default.Model.extend({
name: 'addon-meta-model'
}) {} // normal class body definition here
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
_exports.default = MetaModel;
});
;define("ts-app/models/base-model", ["exports", "side-models/models/meta-model"], function (_exports, _metaModel) {
"use strict";
Object.defineProperty(_exports, "__esModule", {
value: true
});
_exports.default = void 0;
class BaseModel extends _metaModel.default.extend({
baseName: 'baseModel'
}) {} // normal class body definition here
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
_exports.default = BaseModel;
});
;define("ts-app/models/meta-model", ["exports", "ts-app/models/base-model"], function (_exports, _baseModel) {
"use strict";
Object.defineProperty(_exports, "__esModule", {
value: true
});
_exports.default = void 0;
class MetaModel extends _baseModel.default.extend({
fullName: Ember.computed('name', 'baseName', function () {
return this.name + '/' + this.baseName;
})
}) {} // normal class body definition here
// DO NOT DELETE: this is how TypeScript knows how to look up your models.
_exports.default = MetaModel;
}); |
so, for file |
may be related to emberjs/ember-cli-babel#240 |
I think I'm seeing the same issue, but not in testing. Somehow sometimes our prod build causes the consuming apps models to be overwritten by its addon models.
A correct prod build has more define dependencies than what's sometimes seen above. Setup looks like this:
edit: It seems like the error was caused by our CI deploying an old version. It might've been caused by the version using |
@makepanic yeah, now only one solution - if files have same name, both files MUST be |
I've had a hard-to-reproduce problem that may be related to this. Essentially, a production build of our Ember+TypeScript app would not have the application route in it, and this would break the app. The code in The app in question is fully TS, i.e. there are no I've encountered this several times over the last few months, but it was not deterministic and a quick rebuild would fix the problem so it wasn't investigated further. I've seen it in both development and production builds. If it happens again I'll save the output. |
We're still seeing this issue. Is this a ember-cli-typescript or ember-cli issue? I'm currently trying to avoid any conflicts between my app and any addons and will report back how it works out. |
@makepanic all you need - have |
@richard-viney ember-cli/ember-ajax#428 |
How would one handle types in this context? I'd like to not lose the ability to type things. e.g. when configuring the ember-ajax service one usually extends the ajax service. It means i have to either:
|
@makepanic yah, my suggestion - only way to get consistent builds. But, yes, cons - you loose types. |
Related: ember-cli/ember-ajax#428 (comment) |
The summary from that issue:
I'm closing this in favor of #780, where we'll track getting this into docs. Thank you for the report and helping us sort through it! Hopefully getting it into the docs will help users who encounter it. |
@chriskrycho I think it should be |
@lifeart I'm definitely going to make it a loud and clear note, but there's only so much we can do—people have to find and read the docs. 🤷♂ |
@chriskrycho is it make sense to search possible static namespace overlaps on ember-cli boot? |
FYI: .js/.ts collision detection (warning) has been released in v3.1.3 |
reproduction repo: https://github.com/lifeart/ts-merging-issue
how to reproduce?
yarn; ember test; ember test; ember test
or see
same tests failing randomly
case:
ts addon, having model, named
meta-model
,ts app has
base-model
andmeta-model
models.So, sometimes (randomly)
app.base-model
not extends fromaddon.meta-model
and it's produce inconsistent buildThe text was updated successfully, but these errors were encountered: