-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Split i18n engine to specific parts by tech and by env #20513
Conversation
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea in general. I left a few questions and one concern regarding mixing of kbn/i18n reorg changes with intl polyfill, I'd rather split this into two separate PRs.
@@ -0,0 +1,4 @@ | |||
{ | |||
"browser": "../target/web/angular", | |||
"main": "../target/node/angular" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: is there any reason why we need main
(same question for react
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. React
and Angular
is built in order to be used in Node
as well as in browsers (even it will be changed, believe that devs will add 2 different sections as well). And we use Node
environment in tests, and potentially can use ssr where Node
env as well. That's why I split it to 2 parts. Another point - it's babel build. It is just fortuity, that client-preset
is working on server, so we should be consistent with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice use of fortuity
;)
packages/kbn-i18n/package.json
Outdated
"module": "./src/index.js", | ||
"version": "1.0.0", | ||
"license": "Apache-2.0", | ||
"private": true, | ||
"scripts": { | ||
"build": "yarn build:web && yarn build:node", | ||
"build:web": "cross-env BABEL_ENV=web babel src --out-dir target/web", | ||
"build:node": "cross-env BABEL_ENV=node babel src --out-dir target/node", | ||
"build:web": "cross-env BABEL_ENV=web babel src --out-dir target/web --copy-files", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: why do we need --copy-files
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to copy package.json
for correct resolving modules
packages/kbn-i18n/package.json
Outdated
"build:web": "cross-env BABEL_ENV=web babel src --out-dir target/web", | ||
"build:node": "cross-env BABEL_ENV=node babel src --out-dir target/node", | ||
"build:web": "cross-env BABEL_ENV=web babel src --out-dir target/web --copy-files", | ||
"build:node": "cross-env BABEL_ENV=node babel src --out-dir target/node --copy-files", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I still see target/node/angular|react
, would it make sense to use babel src/core
in build:node
or something like that to avoid unnecessary files in target/node
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
point in previous comment
@@ -17,12 +17,6 @@ | |||
* under the License. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: looks like intl polyfill is out of scope for this particular PR, can we add it in a separate PR and not mix two unrelated changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, actually you are absolutely right, but I added because of 2 reasons:
- It is really small change and easy to review, but if I would add it in another PR, it would be blocked.
- In this PR I added support for different envs. And would like to deliver fully working code without
Intl
issues
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is really small change and easy to review
Hmm, can't agree here, it's a new dependency and we should know and discuss all the consequences it may have (e.g. build size). And it's for node-only, does it block anything specific right now in Index Management
localization effort?
but if I would add it in another PR, it would be blocked.
That's totally fine, let's solve issues when they arrive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@azasypkin you are right. moved this logic
@@ -0,0 +1,4 @@ | |||
{ | |||
"browser": "./index.js", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I'd still keep default index.js
for node and browser.js
for browser similar to what is used by npm itself: main
for node and browser
for browser.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right, will fix it, thank you!
@@ -0,0 +1,21 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: btw, why we do we need core/i18n
subfolder, can't we use just core
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it because of next reason: this functionality is used in Angular
and React
wrappers, and here we should also split into browser
and node
implementation as React
for instance is the same for both. Also, I split real core from loader, where we do not have any environment specific code.
💔 Build Failed |
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, the only thing that I'd do differently is to move core/index.js
and core/lodader.js
into src/
root and put everything from core/i18n
into core
directly to reduce seemingly unnecessary nested i18n
folder. But please tell me if I'm missing something.
💚 Build Succeeded |
44132a9
to
4c236db
Compare
💚 Build Succeeded |
💔 Build Failed |
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it.
* split to packages in accordance to specific library * split to packages depending on tech and environment * make env modules names consistent * remove intl polyfilling * move laoder to root, i18n folder to core
* split to packages in accordance to specific library * split to packages depending on tech and environment * make env modules names consistent * remove intl polyfilling * move laoder to root, i18n folder to core
6.x/6.5: 7026148 |
Split i18n engine to specific parts by technology (
core
,React
,Angular
) and by environment (Browser
andNode
)#20466