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

Fix the TS used for the GB-Mobile project. #21324

Merged

Conversation

SergioEstevao
Copy link
Contributor

Description

Make sure only types inside node_modules/@types are used.

This avoids TS to find the ../node_modules/@types inside the gb-mobile
repo that lives one path level up of gutenberg root.

@sirreal does this have impact on the Gutenberg TS checks?

How has this been tested?

Screenshots

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

Make sure only types inside node_modules/@types are used.

This avoids TS to find the ../node_modules/@types inside the gb-mobile
repo that lives one path level up of gutenberg root.
@SergioEstevao SergioEstevao added the Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) label Apr 1, 2020
@github-actions
Copy link

github-actions bot commented Apr 1, 2020

Size Change: +390 B (0%)

Total Size: 884 kB

Filename Size Change
build/block-directory/index.js 6.03 kB +5 B (0%)
build/block-editor/index.js 102 kB -7 B (0%)
build/block-editor/style-rtl.css 10.7 kB -493 B (4%)
build/block-editor/style.css 10.7 kB -489 B (4%)
build/block-library/index.js 110 kB -105 B (0%)
build/components/index.js 195 kB -2 B (0%)
build/components/style-rtl.css 16.6 kB +506 B (3%)
build/components/style.css 16.5 kB +499 B (3%)
build/compose/index.js 6.21 kB +1 B
build/core-data/index.js 10.7 kB +19 B (0%)
build/data/index.js 8.23 kB +1 B
build/edit-navigation/index.js 2.48 kB +84 B (3%)
build/edit-navigation/style-rtl.css 239 B +144 B (60%) 🆘
build/edit-navigation/style.css 241 B +146 B (60%) 🆘
build/edit-post/index.js 92.3 kB -1 B
build/edit-post/style-rtl.css 12 kB -9 B (0%)
build/edit-post/style.css 12 kB -9 B (0%)
build/edit-site/index.js 9.1 kB +57 B (0%)
build/edit-site/style-rtl.css 4.61 kB -5 B (0%)
build/edit-site/style.css 4.61 kB -6 B (0%)
build/editor/index.js 42.8 kB -4 B (0%)
build/editor/style-rtl.css 3.49 kB +24 B (0%)
build/editor/style.css 3.49 kB +24 B (0%)
build/format-library/index.js 6.95 kB +9 B (0%)
build/rich-text/index.js 14.5 kB +2 B (0%)
build/shortcode/index.js 1.69 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.02 kB 0 B
build/annotations/index.js 3.45 kB 0 B
build/api-fetch/index.js 3.8 kB 0 B
build/autop/index.js 2.59 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 760 B 0 B
build/block-library/editor-rtl.css 7.21 kB 0 B
build/block-library/editor.css 7.21 kB 0 B
build/block-library/style-rtl.css 7.5 kB 0 B
build/block-library/style.css 7.51 kB 0 B
build/block-library/theme-rtl.css 669 B 0 B
build/block-library/theme.css 671 B 0 B
build/block-serialization-default-parser/index.js 1.65 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 57.5 kB 0 B
build/data-controls/index.js 1.03 kB 0 B
build/date/index.js 5.37 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 569 B 0 B
build/dom/index.js 3.05 kB 0 B
build/edit-widgets/index.js 4.43 kB 0 B
build/edit-widgets/style-rtl.css 3.74 kB 0 B
build/edit-widgets/style.css 3.74 kB 0 B
build/editor/editor-styles-rtl.css 423 B 0 B
build/editor/editor-styles.css 426 B 0 B
build/element/index.js 4.44 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/hooks/index.js 1.93 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 710 B 0 B
build/keyboard-shortcuts/index.js 2.3 kB 0 B
build/keycodes/index.js 1.7 kB 0 B
build/list-reusable-blocks/index.js 2.99 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/media-utils/index.js 4.84 kB 0 B
build/notices/index.js 1.57 kB 0 B
build/nux/index.js 3.01 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/plugins/index.js 2.54 kB 0 B
build/primitives/index.js 1.5 kB 0 B
build/priority-queue/index.js 780 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/server-side-render/index.js 2.54 kB 0 B
build/token-list/index.js 1.28 kB 0 B
build/url/index.js 4.01 kB 0 B
build/viewport/index.js 1.6 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

@SergioEstevao SergioEstevao requested a review from aduth April 1, 2020 14:11
@aduth
Copy link
Member

aduth commented Apr 1, 2020

I don't think this is what we'd want, since it would prevent TypeScript from being able to use types which are shipped with a package. With these changes, only community-maintained types from DefinitelyTyped would be used. The original package should always be the preferred source of types, with DefinitelyTyped serving as a fallback, often in cases where the upstream package does not ship with their own (like was the case with every @wordpress/ package prior to #18942).

@aduth
Copy link
Member

aduth commented Apr 1, 2020

Oh! I see what you're referring to as far as finding types in parent directories. While my previous point does still stand, and we don't want to be just finding types from @types/ scope, there may still be some solution which still accounts for types from node_modules/ root packages.

I seem to recall having a similar conversation about types or modules being found in parent directories, and something about it "working as intended", so it would be worth finding some clarity on this point.

@SergioEstevao
Copy link
Contributor Author

@aduth I'm open to any suggestions...

@SergioEstevao
Copy link
Contributor Author

SergioEstevao commented Apr 1, 2020

@aduth so the documentation says by default:

By default all visible “@types” packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible; specifically, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.

So this will limit it to one level instead of going up the folder no?

@aduth
Copy link
Member

aduth commented Apr 1, 2020

My initial thinking is that something like this would work:

{
    "typeRoots": [
        "./node_modules",
        "./node_modules/@types"
    ]
}

I'm still a bit unclear:

  1. Order of priority here (@types should be fallback)
  2. Whether this is the behavior we want.

@SergioEstevao
Copy link
Contributor Author

We can also do this

"typeRoots": [./node_modules/**]

@SergioEstevao
Copy link
Contributor Author

SergioEstevao commented Apr 1, 2020

@aduth tested your suggested options and it doesn't work, it fails with TS errors. My second suggestion also does not work.

Do we have another @types folder inside subfolders of node_modules?

@sirreal
Copy link
Member

sirreal commented Apr 1, 2020

This part of config always leaves me confused, but in general I'd expect this PR to be fine.

I don't think this is what we'd want, since it would prevent TypeScript from being able to use types which are shipped with a package.

I don't believe that's the case. When importing a package, TypeScript will still find its types if they're included. This has to do more with automatically included types.

It would be good to verify this one way or another. Redux is an example of a package that includes its types, we could test that out with this PR.

I did mention to @SergioEstevao via another channel that we might reconsider the setup for Gutenberg Mobile, which I'm completely unfamiliar with.

I left some relevant thoughts in a similar situation here: #18531 (comment)

@SergioEstevao
Copy link
Contributor Author

SergioEstevao commented Apr 1, 2020

@aduth the documentation also says:

Keep in mind that automatic inclusion is only important if you’re using files with global declarations (as opposed to files declared as modules). If you use an import "foo" statement, for instance, TypeScript may still look through node_modules & node_modules/@types folders to find the foo package.

So is this configuration only limit were to find @types package but still allow the types defined on files?

@aduth
Copy link
Member

aduth commented Apr 1, 2020

@SergioEstevao I'm not sure, but based on what you've quoted there, my interpretation would be that it may even be supported to specify a typeRoots of an empty array, if TypeScript is going to dive into the local node_modules folders anyways?

@sirreal
Copy link
Member

sirreal commented Apr 1, 2020

An alternative is to set types: []. This disables automatic type inclusion. Types will continue to be pulled in when associated packages are imported.

Any types that aren't part of the lib or included via imports (webpack-env, which modifies globals to include webpack globals is a common one) need to be added manually.

I'm sure there are pitfalls to any of these approaches but I'm not familiar with them. As long as we're not adding anything strange to the types array and the build:package-types script continues to work without error, I think these changes are pretty safe.

@SergioEstevao
Copy link
Contributor Author

An alternative is to set types: []. This disables automatic type inclusion. Types will continue to be pulled in when associated packages are imported.

I tried this but then the script build:package-types fails.

Up until now the configuration I have in this PR is the one that makes the script build and work
inside the GB-mobile project.

@aduth and @sirreal can we approve it as it is?

Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't say that I really understand why it works, but at least in a brief test, this seems to be fine, including when a package ships with their own types.

Tested with the following diff:

diff --git a/packages/i18n/src/create-i18n.js b/packages/i18n/src/create-i18n.js
index 0b0b4cd182..f8c395073c 100644
--- a/packages/i18n/src/create-i18n.js
+++ b/packages/i18n/src/create-i18n.js
@@ -50,7 +50,7 @@ export const createI18n = ( initialData, initialDomain ) => {
 	 *
 	 * @type {Tannin}
 	 */
-	const tannin = new Tannin( {} );
+	const tannin = new Tannin( 10 );
 
 	/**
 	 * Merges locale data into the Tannin instance by domain. Accepts data in a

Error (expected):

packages/i18n/src/create-i18n.js:53:29 - error TS2345: Argument of type '10' is not assignable to parameter of type '{ [domain: string]: { [key: string]: TanninDomainMetadata | [string, string]; '': TanninDomainMetadata | [string, string]; }; }'.

53  const tannin = new Tannin( 10 );
                               ~~


Found 1 error.

@sirreal
Copy link
Member

sirreal commented Apr 1, 2020

An alternative is to set types: []. This disables automatic type inclusion. Types will continue to be pulled in when associated packages are imported.

I tried this but then the script build:package-types fails.

I'm not opposed to this as-is. "types": [ "node" ] works fine in a quick test. It would be nice to narrow this down because using node types in all packages (which I believe we're doing now) doesn't seem quite right.

@SergioEstevao
Copy link
Contributor Author

"types": [ "node" ] works fine in a quick test

This worked fine for GB-mobile too. @sirreal do you prefer to have it like that?

@sirreal
Copy link
Member

sirreal commented Apr 2, 2020

"types": [ "node" ] works fine in a quick test

This worked fine for GB-mobile too. @sirreal do you prefer to have it like that?

With this approved, I'd say go ahead and merge as it is now. It's something that should be revisited either way.

@SergioEstevao SergioEstevao merged commit 5941c92 into master Apr 2, 2020
@SergioEstevao SergioEstevao deleted the rnmobile/fix_typescript_build_inside_gb_mobile branch April 2, 2020 13:37
@github-actions github-actions bot added this to the Gutenberg 7.9 milestone Apr 2, 2020
SergioEstevao added a commit that referenced this pull request Apr 2, 2020
* Fix the TS used for the GB-Mobile project.

Make sure only types inside node_modules/@types are used.

This avoids TS to find the ../node_modules/@types inside the gb-mobile
repo that lives one path level up of gutenberg root.

* Framework: Fix configuration spacing

* Change to types node.

* Revert "Change to types node."

This reverts commit bfb8b7b.

Co-authored-by: Andrew Duthie <andrew@andrewduthie.com>
SergioEstevao added a commit that referenced this pull request Apr 3, 2020
* Add pre to list of block wrappers (#21255)

* Add pre to list of block wrappers

* Share the elements definition between web and native.

* Make constant name all uppercase.

* Rename constant name to be all uppercase

* Rename elements constant to all uppercase

* Fix the TS used for the GB-Mobile project. (#21324)

* Fix the TS used for the GB-Mobile project.

Make sure only types inside node_modules/@types are used.

This avoids TS to find the ../node_modules/@types inside the gb-mobile
repo that lives one path level up of gutenberg root.

* Framework: Fix configuration spacing

* Change to types node.

* Revert "Change to types node."

This reverts commit bfb8b7b.

Co-authored-by: Andrew Duthie <andrew@andrewduthie.com>

* [RNMobile] Dark mode on Android put on the v1.25.0 native release (#21352)

* Revert revert of dark mode impl

* Add pre to list of block wrappers (#21255)

* Add pre to list of block wrappers

* Share the elements definition between web and native.

* Make constant name all uppercase.

* Rename constant name to be all uppercase

* Rename elements constant to all uppercase

Co-authored-by: Marko Savic <savicmarko1985@gmail.com>
Co-authored-by: Sérgio Estêvão <sergioestevao@gmail.com>

Co-authored-by: Andrew Duthie <andrew@andrewduthie.com>
Co-authored-by: Stefanos Togoulidis <stefanostogoulidis@gmail.com>
Co-authored-by: Marko Savic <savicmarko1985@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants