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

Split i18n engine to specific parts by tech and by env #20513

Merged
merged 6 commits into from
Jul 16, 2018

Conversation

yankouskia
Copy link

@yankouskia yankouskia commented Jul 6, 2018

Split i18n engine to specific parts by technology (core, React, Angular) and by environment (Browser and Node)

#20466

@yankouskia yankouskia added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Project:i18n labels Jul 6, 2018
@elastic elastic deleted a comment from elasticmachine Jul 6, 2018
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@azasypkin azasypkin left a 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"
Copy link
Member

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)?

Copy link
Author

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.

Copy link

Choose a reason for hiding this comment

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

nice use of fortuity ;)

"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",
Copy link
Member

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?

Copy link
Author

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

"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",
Copy link
Member

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?

Copy link
Author

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.
Copy link
Member

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?

Copy link
Author

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:

  1. It is really small change and easy to review, but if I would add it in another PR, it would be blocked.
  2. In this PR I added support for different envs. And would like to deliver fully working code without Intl issues

Copy link
Member

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.

Copy link
Author

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",
Copy link
Member

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.

Copy link
Author

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 @@
/*
Copy link
Member

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?

Copy link
Author

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.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@yankouskia yankouskia requested a review from azasypkin July 11, 2018 08:46
@azasypkin azasypkin removed the request for review from epixa July 11, 2018 14:37
Copy link
Member

@azasypkin azasypkin left a 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.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@yankouskia yankouskia requested review from rhoboat and removed request for rhoboat July 12, 2018 09:22
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@azasypkin azasypkin mentioned this pull request Jul 13, 2018
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link

@rhoboat rhoboat left a comment

Choose a reason for hiding this comment

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

I like it.

@yankouskia yankouskia merged commit adc4185 into elastic:master Jul 16, 2018
@yankouskia yankouskia deleted the feature/partial-i18n branch July 16, 2018 14:02
yankouskia pushed a commit to yankouskia/kibana that referenced this pull request Jul 16, 2018
* 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
LeanidShutau pushed a commit to LeanidShutau/kibana that referenced this pull request Aug 1, 2018
* 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
LeanidShutau added a commit that referenced this pull request Aug 2, 2018
* 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
@LeanidShutau
Copy link
Contributor

6.x/6.5: 7026148

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported Project:i18n Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v6.5.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants