-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
CLI-less webpack build #1105
CLI-less webpack build #1105
Conversation
Tried a different approach to tackle the enviroment configurations. Instead of a typescript file, which is replaced based on the environment, this strategy uses json file to hold the configuration. The loader takes the basic config file and applies that environmentspecific changes (change environment.json and environment.production.json).
These are not needed anymore, as webpack and webpack-dev-server CLIs are directly used to build and run the app.
- Moved the environment jsons to another directory - Added options to load json modules in tsconfig - Changed the imports for environment - Lastly cleaned up loader with external package
Removed limiting options, so that ts-loader can compilespec.ts files during tests.
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.
One more question, I didn't see you remove aurelia-cli from final package.json of webpack app. Is unit tests still using au test
command?
}, | ||
// @endif | ||
// @if feat.typescript | ||
{ test: /\.ts$/, loader: "ts-loader", options: { reportFiles: [ srcDir+'/**/*.ts'] }, include: srcDir }, |
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.
I think you accidentally removed this line from master.
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.
Ok, saw your commit message for this one too. I guess the side effect is that you have to turn on typeRoots unconditionally, which is not idea.
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.
My earlier take on the typeRoots involving monorepo might be little bit premature, as I have not recently tried to create a monorepo for a aurelia project. I tried that that a year back, and there were massive problems with resolving/loading symlinked packages; the webpack config was crowded with alias
es. If this is a blocker, I will try to create a lerna prototype, and report the the findings.
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.
I tried to create a monorepo using au-cli and lerna. I couldn't make it work. It is not really because of the type definition, which makes the problem I suspected earlier. But even after fixing the typeRoots, Aurelia has problems loading the custom elements coming from different plugins. I opened an issue before on similar problem. I think the problems related to loading the symlinked packages needs to corrected before starting with bootstrapping lerna monorepo projects with lerna.
On the other hand, this typing issue with Jasmine is already opened here: DefinitelyTyped/DefinitelyTyped#14569. If type definition of jasmine is got resolved, probably the whole typeRoots
thing can be done away with.
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.
I also discovered another bug with limiting ts-loader include. I am running release-check on v1 candidate, where I need to modify it to include: karma ? [srcDir, testDir] : srcDir
to fix webpack+karma setup.
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.
Yes, I faced that too. Otherwise the *.spec.ts
files are never processed, and webpack throws error. I think not having the include
for ts-loader
is far easier solution.
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.
I see. I will retain the "include" for v1 release. Then we can work on your big refactoring after v1.
@@ -32,10 +32,8 @@ | |||
"types": ["node", "jest"], | |||
// @endif | |||
|
|||
// @if feat.webpack && feat['postcss-typical'] && feat.protractor |
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.
I think you accidentally removed some lines?
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.
Ok, I saw your commit message. But we did this conditional typeRoots to do minimum impact for users of lerna (where "./node_modules/@types"
does not work).
Sidenote: this is technically a breaking change for webpack app. But it's practically not a breaking change, because it doesn't affect/break existing webpack apps. This only affects newly created webpack app. |
Yup, those are still based on |
I thought our target is to remove runtime dependency on aurelia-cli for webpack app. |
I misunderstood it to be a task to remove the |
No rush, we appreciate your work on this. As this is likely a post-v1 improvement, you have plenty of time. |
BTW, please follow the commit message convention to be properly logged in changelog and release note. https://github.com/DurandalProject/about/blob/master/CONTRIBUTING.md#commit |
Missed the git commit message guideline clearly. Will adhere to that in following commits. |
You can squash all commits into one if you want, that can avoid some similar entries from multiple commits in changelog. |
Usage of aurelia-cli is removed from building and running the webpack apps. This gives developers more control over webpack, and a way to easily change the configuration, without aurelia-cli meddling in between. The commands `au run` or `au build` will not work anymore in the webpack apps, use `npm start`, or `npm run build` instead. This commit closes the webpack part of the the issue aurelia#1098.
Just wanted to point out that this pull request sort of addresses #1039 as well. |
FYI, it's not |
bump |
We need to polish it up, and have some kind of plan to handle this kind of breaking change. We (Sayan included) are all bit busy with Aurelia 2 😅 , not spending enough energy here. |
Force push is fine. |
@fkleuver @3cp I tried to squash all the changes, but there are many conflicting changes. These changes have got pretty old and the fork got also out of sync. I think at this point it is best to create a new PR. I have started another branch that contains all the changes squashed into one commit that includes your suggestions. That branch is also synced with the Aurelia master. Currently I am running the release checks, once that is done, I would like to create a new PR and close this one. Let me if you think otherwise. |
Closed in favor of #1137 |
So can this be used now? |
Sorry @alexdresko you need to wait till #1137 is merged and published. |
@Sayan751 Okay now can we use this? :) |
This PR resolves #1098.
Summary of changes:
*.spec.ts
files during test with karma(+webpack).package.json
,aurelia_project/tasks
, and release check tests. For pre-build cleanup activity, there is a small gulpfile introduced.tsconfig.json
to havetyperoots
applied for all cases, without that the release checks were failing for couple of suites. Other changes here enable loading a json file with ES6 import syntax.environment.ts
s to json files, which are loaded using the app-settings-loader.