Skip to content

Feature request: Adding a lib from npm should not be a 5-step process. #882

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

Closed
SethDavenport opened this issue May 21, 2016 · 18 comments
Closed

Comments

@SethDavenport
Copy link

SethDavenport commented May 21, 2016

Please provide us with the following information:

  1. OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

Mac OS X (El Capitan)

  1. Versions. Please run ng --version. If there's nothing outputted, please
    run in a Terminal:
    node --version
    And paste the result here.

angular-cli: 1.0.0-beta.5
node: 6.0.0
os: darwin x64

(node 6.0.0)

  1. Repro steps. Was this an app that wasn't created using the CLI? What change did you
    do on your code? etc.

This is more of a feature request than a bug. However taking a look at this page in the docs https://github.com/angular/angular-cli/wiki/3rd-party-libs begs a question: why is integrating a lib from npm this complex?

In webpack it's just npm install --save foo (and maybe typings install --save foo). I understand that SystemJS requires a lot more config, which is one reason I have avoided it in the past.

However if we must go with SystemJS it would be nice to provide a wrapper command at least (e.g. ng install --save foo); adding 3rd-party deps is a common operation which other toolchains make fairly simple.

@nfantone
Copy link

What's the reason all of that boilerplate couldn't be automatically derived from package.json?

I mean,

  1. vendorNpmFiles: ['moment/moment.js'] in angular-cli-build.js
  2. 'moment': 'vendor/moment/moment.js' in system-config.ts

Can both be easily extracted and generated dinamically from package.json at build time.

@SethDavenport
Copy link
Author

One advantage of SystemJS over Webpack is the ability to dynamically load modules in the browser, in dev mode.

Unfortunately async module loading is a feature I typically avoid. The large number of HTTP requests it produces makes it unsuitable for production; and the existence of source maps means that you can have a decent dev mode experience even with a single JS bundle created using commonJS at build-time.

So the main feature of SystemJS (or async module loaders in general) is something that I don't find very useful; this makes its extra layers of config on top of package.json even more troublesome.

That said I'm sure you have good reasons for doing it this way. Therefore something to automate the addition of npm modules would be appreciated if at all possible.

@TheLarkInn
Copy link
Member

@SethDavenport webpack supports async module loading (not that you would need it for dev env), additionally it has webpack-dev-server that is a 2 line setup that has multiple varieties of sourcemaps available (depending on how fast you want your builds to run), and support incremental HMR, and watch.

@SethDavenport
Copy link
Author

@TheLarkInn oh, I know :) I use webpack most of the time ... huge fan.

@filipesilva
Copy link
Contributor

filipesilva commented Jun 2, 2016

Yeah the 3rd party lib scenario isn't very friendly. As far as contrasting it with webpack, that discussion is underway on #909.

Regarding the boilerplate... a lot of config can't be derived, and even if it could not all installed npm packages should be added to SystemJS.

I'm leaving this issue open for people to pitch in suggestions on how the current 3rd party libs journey could be improved, but please let's keep the system vs webpack vs whatever out of it.

@nfantone
Copy link

nfantone commented Jun 2, 2016

Regarding the boilerplate... a lot of config can't be derived, and even if it could not all installed npm packages should be added to SystemJS.

Why not? What do we lose/gain? Trimming the final build?

Couldn't we solve this by adding a simple --yes-I-want-this-to-be-added-to-systemjs flag when installing with npm i in tandem with a "postinstall" script?

@filipesilva
Copy link
Contributor

Trimming the final build is a concern, yes. The tree shaking might take care of it automatically though.

A postinstall script could maybe work, although I'm not sure of the technical details of making that work. For instance, how to get the installed package names, how to auto determine the module format.

Also it would require a custom flag on install or something similar, which is already deviating from how users would expect npm install to work.

@nfantone
Copy link

nfantone commented Jun 6, 2016

@filipesilva

Also it would require a custom flag on install or something similar, which is already deviating from how users would expect npm install to work.

Understood. But the only alternatives I can think of are actually worse: manually editing files or an entirely new CLI tool/command. Have you ever considered integrating jspm?

@filipesilva
Copy link
Contributor

@nfantone we did at a time, but it suffered from a similar problem: you'd need to install packages using something other than npm. It'd configure systemjs for you, which was a plus, but wouldn't configure CLI stuff and there was no clear integration with ember-cli.

So at the time we didn't pursue it more. That is, of course, something that might change.

@nfantone
Copy link

nfantone commented Jun 7, 2016

Is dynamic module loading even a hard requirement? What about old school <script> tags? I'd go that way every time if it meant to keep using the tools we all know.

@TheLarkInn
Copy link
Member

TheLarkInn commented Jun 7, 2016

We want to make it a seamless process for people to use. Therefore when somone does ng install some-lib we need to do the following:

  • fetch module from npm via npm install
    • optionally install types from @types/some-lib
  • if there is a way to determine what kind of module it is (we need to tell said builder how to resolve it in the build process)
  • import the module into vendors file.
  • import the typings for the file.

Maybes:

  • if can't determine what kind of module the some-lib is, need to warn/notify the user (if really needed).

@nfantone
Copy link

nfantone commented Jun 7, 2016

@TheLarkInn I'd like to refer you to #845 (comment).

  • Points one to three are already solved by jspm - or, at least, it tries to do so.
  • Types are installed by typings.

Remaining things are CLI-related. We should find a way to get rid or work around those. Why do need yet another tool?

@TheLarkInn
Copy link
Member

@nfantone Not debating that. I'm just leaving some points that should be covered however/whenever it is implemented.

@nxpatterns
Copy link

+1

@intellix
Copy link
Contributor

intellix commented Jul 12, 2016

For packages that have their own dependencies, this is more like 100x step process for including third-party processes. Been trying to include @horizon/client for a couple of hours now and still haven't managed it.

For that third-party lib alone, this is what I have so far to try and load all of it's individual dependencies and I'm still getting 404 errors from SystemJS:

/** Map relative paths to URLs. */
const map: any = {
  '@horizon/client': 'vendor/@horizon/client/dist',
  'ws': 'vendor/engine.io-client/lib',
  'babel-runtime': 'vendor/babel-runtime',
  'snake-case': 'vendor/snake-case',
  'sentence-case': 'vendor/sentence-case',
  'lower-case': 'vendor/lower-case',
  'engine.io-client': 'vendor/engine.io-client/lib',
  'engine.io-parser': 'vendor/engine.io-parser/lib',
  'isomorphic-fetch': 'vendor/isomorphic-fetch',
  'core-js': 'vendor/core-js',
};

/** User packages configuration. */
const packages: any = {
  '@horizon/client': { main: 'horizon-dev' },
  'ws': { main: 'index' },
  'babel-runtime': { main: 'index' },
  'snake-case': { main: 'snake-case' },
  'sentence-case': { main: 'sentence-case' },
  'lower-case': { main: 'lower-case' },
  'engine.io-client': { main: 'index' },
  'engine.io-parser': { main: 'index' },
  'isomorphic-fetch': { main: 'index' },
  'core-js': { main: 'index' },
};

I refresh the page, and get another 5 more 404 errors. This sort of thing is exactly what JSPM is trying to solve.
You want to include one third-party library and not have to configure where to find all of it's own dependencies from.

After telling SystemJS where to find Horizon's dependencies, I'm now getting 404s that need mapping for some more: component-emitter, debug, indexof, parseuri, parsejson, parsegs, utf8, after
Adding 1 library can be anything between 2 minutes -> 5hrs - I want to cry :'(

@nfantone
Copy link

I want to cry :'(

We feel you, brother.

hansl pushed a commit that referenced this issue Jul 14, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes #909 #1155 #882
filipesilva pushed a commit that referenced this issue Jul 15, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes #909 #1155 #882
hansl added a commit that referenced this issue Jul 27, 2016
* build: use webpack for building apps.

This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes #909 #1155 #882

* chore(lint) Corrected any eslint errors and cleaned up unused files

* chore(cleanup) additional cleanup tasks performed. Removed unneeded code, indentation causing linting errors, add back tsconfig sourcemapping, removed console logs, deleted material unused files.

* chore: remove bind from serve command

* chore: simplify test command

* chore: fix test warnings

* chore: revert whitespace changes

* chore: re-add mapRoot to tsconfig

* chore: remove unused import

* bugfix: fix broken tests

* fix: fix mobile-specific feature test

* bugfix: fix public folder test

* fix: fixes for path mappings, tests, and coverage (#1359)

* fix(): Multiple fixes for path mappings:

* Removed invalid test case that was throwing path mappings  tests because of a typescript bug.
* Readded PathsPlugin for Path Mappings
* Removed coverage preprocessor which was throwing bad type errors against ts code when it shouldn't be.
* Added sourcemap support for istanbul instrumenter. Coverage files are still being generated.

* fix: fix the way the build command runs for mobile tests

* fix: fix the way the build command runs for mobile tests

* fix: replaced promise based ng command with sh.exec to allow mappings test to run correctly against mobile

* fix: replaced promise based ng command with sh.exec to allow mappings test to run correctly against mobile

* fix: add environment configuration replacement (#1364)

* fix: add environment configuration replacement

* remove debuggers

* fix: move mobile test above config test because it relies on prod build from previous step

* fix: removed unneeded interface moved config paths

* fix(tests): re-enable sass/less/stylus tests (#1363)

* chore: remove systemjs (#1376)

* chore: remove vendor.ts (#1383)

* chore: remove material2 test option (#1385)

* fix(build): re-add support for sourceDir (#1378)

* chore(build): remove broccoli (#1386)

* chore: remove windows elevation check (#1384)

* fix(test): add missing sourceDir (#1387)

* fix: update node polyfill support properties for prod config to allow dev-server (aka ng serve) (#1395)

* chore(tests): add prod env e2e test (#1394)

* chore: cleanup of new files (#1388)

* fix(serve): disable HMR (#1402)

* chore: review docs (#1407)

* feat(env): decouple build from env file (#1404)

* fix: fix tsconfig for editors (#1420)

* chore: fix webpack branch after merge conflicts (#1423)

* fix: update to awesome-typescript-loader 2.1.0 (#1425)

* fix: update to awesome-typescript-loader 2.1.0 which fixes a few issues shimming typings libs in tsconfig.json

* fix: forgot to set libs in tsconfig blueprint

* chore(blueprints): remove module.id (#1426)

* feat: add host flag support for ng serve (#1442)

* feat(test): add karma plugin (#1437)

* chore(blueprints): re-add outDir (#1428)

* feat: use @types instead of typings (#1449)

* fix: make sourcemaps work in test (#1447)

* feat: add utilities for typescript ast (#1159) (#1453)

'ast-utils.ts' provides typescript ast utility functions
@filipesilva
Copy link
Contributor

Fixed in #1455.

Splaktar pushed a commit to DevIntent/angular-cli that referenced this issue Jul 31, 2016
* build: use webpack for building apps.

This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882

* chore(lint) Corrected any eslint errors and cleaned up unused files

* chore(cleanup) additional cleanup tasks performed. Removed unneeded code, indentation causing linting errors, add back tsconfig sourcemapping, removed console logs, deleted material unused files.

* chore: remove bind from serve command

* chore: simplify test command

* chore: fix test warnings

* chore: revert whitespace changes

* chore: re-add mapRoot to tsconfig

* chore: remove unused import

* bugfix: fix broken tests

* fix: fix mobile-specific feature test

* bugfix: fix public folder test

* fix: fixes for path mappings, tests, and coverage (angular#1359)

* fix(): Multiple fixes for path mappings:

* Removed invalid test case that was throwing path mappings  tests because of a typescript bug.
* Readded PathsPlugin for Path Mappings
* Removed coverage preprocessor which was throwing bad type errors against ts code when it shouldn't be.
* Added sourcemap support for istanbul instrumenter. Coverage files are still being generated.

* fix: fix the way the build command runs for mobile tests

* fix: fix the way the build command runs for mobile tests

* fix: replaced promise based ng command with sh.exec to allow mappings test to run correctly against mobile

* fix: replaced promise based ng command with sh.exec to allow mappings test to run correctly against mobile

* fix: add environment configuration replacement (angular#1364)

* fix: add environment configuration replacement

* remove debuggers

* fix: move mobile test above config test because it relies on prod build from previous step

* fix: removed unneeded interface moved config paths

* fix(tests): re-enable sass/less/stylus tests (angular#1363)

* chore: remove systemjs (angular#1376)

* chore: remove vendor.ts (angular#1383)

* chore: remove material2 test option (angular#1385)

* fix(build): re-add support for sourceDir (angular#1378)

* chore(build): remove broccoli (angular#1386)

* chore: remove windows elevation check (angular#1384)

* fix(test): add missing sourceDir (angular#1387)

* fix: update node polyfill support properties for prod config to allow dev-server (aka ng serve) (angular#1395)

* chore(tests): add prod env e2e test (angular#1394)

* chore: cleanup of new files (angular#1388)

* fix(serve): disable HMR (angular#1402)

* chore: review docs (angular#1407)

* feat(env): decouple build from env file (angular#1404)

* fix: fix tsconfig for editors (angular#1420)

* chore: fix webpack branch after merge conflicts (angular#1423)

* fix: update to awesome-typescript-loader 2.1.0 (angular#1425)

* fix: update to awesome-typescript-loader 2.1.0 which fixes a few issues shimming typings libs in tsconfig.json

* fix: forgot to set libs in tsconfig blueprint

* chore(blueprints): remove module.id (angular#1426)

* feat: add host flag support for ng serve (angular#1442)

* feat(test): add karma plugin (angular#1437)

* chore(blueprints): re-add outDir (angular#1428)

* feat: use @types instead of typings (angular#1449)

* fix: make sourcemaps work in test (angular#1447)

* feat: add utilities for typescript ast (angular#1159) (angular#1453)

'ast-utils.ts' provides typescript ast utility functions
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Aug 15, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Aug 15, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Aug 24, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Aug 24, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Aug 25, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 6, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 7, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 11, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 14, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 15, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 16, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 19, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 20, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 21, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
devCrossNet pushed a commit to devCrossNet/universal-cli that referenced this issue Sep 23, 2016
This pull request replaces the underlying broccoli build system and then
replaces it with webpack as the build and bundler.

This will affect the following commands (however the user-level)
functionality should go unchanged (besides unimplemented flags which
will come after this PR.):

ng build (with --env flag and --watch flag supported)
ng serve (with --port flag supported)
ng test / ng e2e

The webpack configuration is blackboxed, and therefore users will not
see a webpack.config.js file in their repository.

Also this PR will bump the typescript version to 2.0 (beta).

Fixes angular#909 angular#1155 angular#882
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants