Add --package_json_entry_names command line flag
#2600
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
FYI, I won't have time to look at this today. |
|
Thanks for setting expectations. No rush. |
|
Also, you may be amused to know that your previous PR crashed the tool we use to bring PRs internally, because of the unicode character ó in your name :) So I had to edit the script to add the name without the accent. Consider using the name without the accent in your git settings to avoid this in the future. (Up to you, we can work around this, just thought I'd let you know.) |
|
that's just too funny 😃 I can do that in my git settings, I should probably amend this commit then. |
|
Just amended this commit to not include the ó character in the author line. |
|
+1 we need this for Angular as well, @jasonaden and I built locally and tested today. |
ChadKillingsworth
requested changes
Aug 8, 2017
There was a problem hiding this comment.
I'd like to land #2604 first. Can we change this to default to the list browser, module, main? That's what webpack uses.
|
@ChadKillingsworth fixed and squashed commits. Any other notes? |
| @Option(name = "--package_json_entry_names", | ||
| usage = "Ordered list of entries to look for in package.json files when processing " | ||
| + "modules with the NODE module resolution strategy (i.e. esnext:main,browser,main). " | ||
| + "Defaults to a list with a single entry, \"main\"." |
There was a problem hiding this comment.
Need to update this comment.
There was a problem hiding this comment.
Nice catch. fixed.
anmonteiro
commented
Aug 8, 2017
| * Needed by {@link RewriteJsonToModule}, but defined here because RewriteJsonToModule is not | ||
| * part of the core build. | ||
| */ | ||
| public static final String PACKAGE_JSON_MAIN = "main"; |
There was a problem hiding this comment.
this is not actually used anywhere else, since we generalized package.json fields.
There was a problem hiding this comment.
Then I'd just remove it.
There was a problem hiding this comment.
It's removed. My comment is to justify the deletion.
ChadKillingsworth
approved these changes
Aug 8, 2017
jelbourn
added a commit
to jelbourn/components
that referenced
this pull request
Sep 12, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
jelbourn
added a commit
to jelbourn/components
that referenced
this pull request
Sep 12, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
jelbourn
added a commit
to jelbourn/components
that referenced
this pull request
Sep 12, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
jelbourn
added a commit
to jelbourn/components
that referenced
this pull request
Sep 12, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
jelbourn
added a commit
to jelbourn/components
that referenced
this pull request
Sep 13, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
jelbourn
added a commit
to jelbourn/components
that referenced
this pull request
Sep 13, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
mmalerba
pushed a commit
to angular/components
that referenced
this pull request
Sep 14, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
josephperrott
pushed a commit
to josephperrott/components
that referenced
this pull request
Sep 15, 2017
Before this change, all of `@angular/material` was bundled into a
single, flat JS file.
After this change, each top-level component (i.e., each directory under
`src/lib`) will be have its own JS file (and d.ts and metadata.json).
The benefit of this change is that current versions of webpack will be
able to do a much better job of only including the code an app is using.
It also allows (but does not require) people to explicitly import from specific components,
e.g.
```
import {MdButtonModule} from '@angular/material/button';
``
For development _within Angular Material itself_ we have to use these
deeper imports because the root `@angular/material` doesn't exist until
we build the relase package.
Additionally, this PR adds a `tsconfig.json` for each dir under `src/`
with the correct path mappings for that directory, so that IDEs will
correctly generate imports.
Closure Compiler CI check is also disabled by this PR; it cannot work
with the new package structure until a release with
google/closure-compiler#2600 is made available.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR builds on #2598 and adds a command line flag that allows specifying the ordered entries which
RewriteJsonToModuleshould look for when computing the main entry inpackage.jsonfiles.refs #2433