Skip to content
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

not obvious how to get a working nodejs require given our module_name semantics #565

Closed
alexeagle opened this issue Dec 17, 2018 · 3 comments
Assignees

Comments

@alexeagle
Copy link
Collaborator

Maybe we could have a way to set a default function for creating module names when installing the typescript rules?

For example, in the angular/angular repo we always want to map
angular/packages/[pkg]/* -> @angular/[pkg]/*

we should be able to do this in one place and not set module_name attribute everywhere.

kyliau referenced this issue in kyliau/angular Dec 17, 2018
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360

With that fixed, `ng test` now works.

`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.
kyliau referenced this issue in kyliau/angular Dec 17, 2018
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360

With that fixed, `ng test` now works.

`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.
kyliau referenced this issue in kyliau/angular Dec 17, 2018
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360

With that fixed, `ng test` now works.

`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.
@kyliau kyliau self-assigned this Dec 18, 2018
mhevery referenced this issue in angular/angular Dec 18, 2018
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360

With that fixed, `ng test` now works.

`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.

PR Close #27715
mhevery referenced this issue in angular/angular Dec 18, 2018
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360

With that fixed, `ng test` now works.

`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.

PR Close #27715
ngfelixl referenced this issue in ngfelixl/angular Jan 28, 2019
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360

With that fixed, `ng test` now works.

`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.

PR Close angular#27715
@alexeagle
Copy link
Collaborator Author

Note, I did this locally in the angular repo in the tools/defaults.bzl, so the urgency is low

@alexeagle alexeagle transferred this issue from bazelbuild/rules_typescript Feb 22, 2019
@alexeagle
Copy link
Collaborator Author

maybe we should go with #563 and use package.json file to indicate where the package is rooted and what is its name

@alexeagle
Copy link
Collaborator Author

Closing as a dupe of #563

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants