Bug Report or Feature Request (mark with an x)
- [x] bug report -> please search issues before submitting
- [x] feature request
Versions.
$ ng --version
_ _ ____ _ ___
/ \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | |
/ ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___|
|___/
@angular/cli: 1.3.0-beta.0
node: 6.10.1
os: darwin x64
@angular/animations: error
@angular/common: error
@angular/compiler: error
@angular/core: 4.3.1
@angular/forms: error
@angular/http: error
@angular/platform-browser: error
@angular/platform-browser-dynamic: error
@angular/router: error
@angular/cli: error
@angular/compiler-cli: error
@angular/language-service: errorThis in itself manifests the error.
Repro steps.
A full repro can be found at GitHub repo spektrakel-blog/a-glimpse-at-yarn-workspaces
Initially, faced the "You seem to not be depending on @angular/core" error.
This goes down to a sanity check whether Angular is installed as a local dependency.
However, there are more errors with yarn workspaces, when dependencies from a workspace (or "sub-project", or "sub-package") are installed to the top-most node_modules directory of the workspaces root.
Then, it ends up w/ file structure:
Workspace root package.json:
"workspaces": [
"packages/*",
"demo"
]Demo workspace package.json:
{
"name": "demo",
"version": "0.0.0",
"license": "MIT",
"private": true,
"dependencies": {
"@angular/common": "^4.2.4",
"@angular/core": "^4.2.4",
"@angular/forms": "^4.2.4",
"@angular/http": "^4.2.4"
}
}Now, dependencies are installed to node_modules and not to demo/node_modules:
$ ls -a demo/node_modules/
. .. .bin .yarn-integrity
$ ls -a node_modules/@angular
. common forms platform-browser-dynamic
.. compiler http router
animations compiler-cli language-service tsc-wrapped
cli core platform-browser
Then, running ng build from the demo folder errors:
$ cd demo
$ yarn build
yarn build v0.27.5
$ ng build
You seem to not be depending on "@angular/core". This is an error.
error Command failed with exit code 2.
As a workaround, it's possible to symlink "@angular/core":
$ mkdir -p ./node_modules/@angular
$ ln -sf ../../../node_modules/@angular/core ./node_modules/@angular/core
$ ls -l node_modules/@angular/core
lrwxr-xr-x ... node_modules/@angular/core -> ../../../node_modules/@angular/core
$ cat node_modules/@angular/core/package.json
{
"name": "@angular/core",
"version": "4.3.1",
"description": "Angular - the core framework",
"main": "./bundles/core.umd.js",
...
}But then we only get one error further until:
$ yarn build
yarn build v0.27.5
$ ng build
Hash: a90d0476b33232a953c1
Time: 53409ms
chunk {0} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 177 kB {3} [initial] [rendered]
chunk {1} styles.bundle.js, styles.bundle.js.map (styles) 10.5 kB {3} [initial] [rendered]
chunk {2} main.bundle.js, main.bundle.js.map (main) 1.89 MB [initial] [rendered]
chunk {3} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]
WARNING in ../~/@angular/compiler/@angular/compiler.es5.js
(Emitted value instead of an instance of Error) Cannot find source file 'compiler.es5.ts': Error: Can't resolve './compiler.es5.ts' in '/Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/compiler/@angular'
@ ../~/@angular/platform-browser-dynamic/@angular/platform-browser-dynamic.es5.js 7:0-72
@ ./src/main.ts
@ multi ./src/main.ts
ERROR in Error encountered resolving symbol values statically. Function calls are not supported. Consider replacing thefunction or lambda with a reference to an exported function (position 194:50 in the original .ts file), resolving symbol NgModule in /Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/core/core.d.ts, resolving symbol BrowserModule in /Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/platform-browser/platform-browser.d.ts, resolving symbol BrowserModule in /Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/platform-browser/platform-browser.d.tsWhich suggests that Angular CLI isn't really meant to work w/ "sub-projects" like yarn worksapces.
The log given by the failure.
See above.
Desired functionality.
Angular CLI and webpack should resolve depndencies from "top-level" node_modules.
The sanity check should honor node's module resolution algorithm (looking up recursively up the file tree).
Mention any other details that might be useful.
Related to #6504
A related change was implemented in #6475 (resolve in all available node_modules), but it seems that it does not address this use case.
Bug Report or Feature Request (mark with an
x)Versions.
$ ng --version _ _ ____ _ ___ / \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _| / △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | | / ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | | /_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___| |___/ @angular/cli: 1.3.0-beta.0 node: 6.10.1 os: darwin x64 @angular/animations: error @angular/common: error @angular/compiler: error @angular/core: 4.3.1 @angular/forms: error @angular/http: error @angular/platform-browser: error @angular/platform-browser-dynamic: error @angular/router: error @angular/cli: error @angular/compiler-cli: error @angular/language-service: errorThis in itself manifests the error.
Repro steps.
A full repro can be found at GitHub repo spektrakel-blog/a-glimpse-at-yarn-workspaces
Initially, faced the "You seem to not be depending on @angular/core" error.
This goes down to a sanity check whether Angular is installed as a local dependency.
However, there are more errors with yarn workspaces, when dependencies from a workspace (or "sub-project", or "sub-package") are installed to the top-most
node_modulesdirectory of the workspaces root.Then, it ends up w/ file structure:
Workspace root
package.json:Demo workspace
package.json:{ "name": "demo", "version": "0.0.0", "license": "MIT", "private": true, "dependencies": { "@angular/common": "^4.2.4", "@angular/core": "^4.2.4", "@angular/forms": "^4.2.4", "@angular/http": "^4.2.4" } }Now, dependencies are installed to
node_modulesand not todemo/node_modules:Then, running
ng buildfrom thedemofolder errors:As a workaround, it's possible to symlink "@angular/core":
But then we only get one error further until:
$ yarn build yarn build v0.27.5 $ ng build Hash: a90d0476b33232a953c1 Time: 53409ms chunk {0} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 177 kB {3} [initial] [rendered] chunk {1} styles.bundle.js, styles.bundle.js.map (styles) 10.5 kB {3} [initial] [rendered] chunk {2} main.bundle.js, main.bundle.js.map (main) 1.89 MB [initial] [rendered] chunk {3} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered] WARNING in ../~/@angular/compiler/@angular/compiler.es5.js (Emitted value instead of an instance of Error) Cannot find source file 'compiler.es5.ts': Error: Can't resolve './compiler.es5.ts' in '/Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/compiler/@angular' @ ../~/@angular/platform-browser-dynamic/@angular/platform-browser-dynamic.es5.js 7:0-72 @ ./src/main.ts @ multi ./src/main.ts ERROR in Error encountered resolving symbol values statically. Function calls are not supported. Consider replacing thefunction or lambda with a reference to an exported function (position 194:50 in the original .ts file), resolving symbol NgModule in /Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/core/core.d.ts, resolving symbol BrowserModule in /Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/platform-browser/platform-browser.d.ts, resolving symbol BrowserModule in /Users/David/Projects/github/spektrakel-blog/a-glimpse-at-yarn-workspaces/node_modules/@angular/platform-browser/platform-browser.d.tsWhich suggests that Angular CLI isn't really meant to work w/ "sub-projects" like yarn worksapces.
The log given by the failure.
See above.
Desired functionality.
Angular CLI and webpack should resolve depndencies from "top-level"
node_modules.The sanity check should honor node's module resolution algorithm (looking up recursively up the file tree).
Mention any other details that might be useful.
Related to #6504
A related change was implemented in #6475 (resolve in all available node_modules), but it seems that it does not address this use case.