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

Move @elastic/datemath into monorepo #16531

Merged
merged 65 commits into from
Feb 13, 2018

Conversation

kimjoar
Copy link
Contributor

@kimjoar kimjoar commented Feb 5, 2018

This pulls in @elastic/datemath to the monorepo, renames it to @kbn/datemath, and cleans up a couple things.

This will require yarn kbn bootstrap instead of just yarn, as you'll otherwise see errors like:

/Users/kim/dev/elastic/master/kibana/src/core_plugins/kibana/public/discover/controllers/discover.js
  6:22  error  Unable to resolve path to module '@kbn/datemath'  import/no-unresolved

or

ERROR in ./src/ui/public/vislib/visualizations/time_marker.js
Module not found: Error: Can't resolve '@kbn/datemath' in '/Users/kim/dev/elastic/master/kibana/src/ui/public/vislib/visualizations'

as the @kbn/datemath package needs to be built before it can be used.

NOTE: This does not work with Kibana plugins until #16509 and elastic/kibana-plugin-helpers#57 are merged.

https://github.com/elastic/x-pack-kibana/pull/4505 is using it in x-pack.

@kimjoar kimjoar added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Feb 5, 2018
@epixa
Copy link
Contributor

epixa commented Feb 5, 2018

This is a package, not a plugin, right?

@kimjoar kimjoar changed the title Production plugin example: datemath Production package example: datemath Feb 5, 2018
@kimjoar kimjoar added the WIP Work in progress label Feb 5, 2018
@kimjoar
Copy link
Contributor Author

kimjoar commented Feb 5, 2018

🙈 Yep. Still a WIP, I'm just exploring the flow when using a package like this across Kibana and x-pack (or any other plugin).

@kimjoar kimjoar force-pushed the platform/import-datemath branch 3 times, most recently from adc06f5 to 4baff7e Compare February 5, 2018 23:43
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elastic elastic deleted a comment from elasticmachine Feb 6, 2018
@elastic elastic deleted a comment from elasticmachine Feb 6, 2018
@kimjoar
Copy link
Contributor Author

kimjoar commented Feb 6, 2018

Okey, this is ready to review

@kimjoar kimjoar removed the WIP Work in progress label Feb 6, 2018
@azasypkin azasypkin self-requested a review February 6, 2018 14:35
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.

Code LGTM, just a couple of minor nits/questions + please add trailing new lines to all new files. Going to run Kibana and find the places where this package is used, so keeping r? for now

@@ -117,6 +117,9 @@ For more details, run:
yarn kbn
```

Bootstrapping also calls the `kbn:boostrap` script for every included project.
This is intended for packages that needs to be built/transpiled to be usable.
Copy link
Member

Choose a reason for hiding this comment

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

typo: that needs ---> that need?


/**
* At the end of the bootstrapping process we call all `kbn:bootstrap` scripts
* in the list of projects. We do this because some projects needs to be
Copy link
Member

Choose a reason for hiding this comment

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

typo: needs --> need.

lib
node_modules
npm-debug.log
yarn.lock
Copy link
Member

Choose a reason for hiding this comment

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

question: don't we want to commit yarn.lock? Also do we need .gitignore in the package itself?

Same question for .npmignore, why do we need this? We have private: true in the package.json so it doesn't seem like we want to ever publish this package.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, yarn.lock can stay now that we aren't installing from npm, and the rest of the stuff in this file is redundant, so I removed the file

Copy link
Contributor

Choose a reason for hiding this comment

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

Also the .npmignore file

Copy link
Contributor Author

Choose a reason for hiding this comment

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

++ good catch

export async function prepareProjectDependencies(settings, logger) {
await handleLinkDependencies(
settings.workingPath,
logger
Copy link
Member

Choose a reason for hiding this comment

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

nit: looks like you don't use logger in handleLinkDependencies.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

const depVersion = deps[depName];

if (depVersion.startsWith(LINK_DEP)) {
if (isKibanaDep) {
Copy link
Member

Choose a reason for hiding this comment

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

issue: it's always true since you don't call isKibanaDep function at all (looks like it needs a simple test) :)

Also is there any reason why we don't want to just use if (depVersion.startsWith(LINK_DEP) && !isKibanaDep(depVersion) without nested empty if? We can easily expand it once we need it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Haha 🙈 I've added some tests for it. And fixed the if too (initially did it like that because I had code in the "kibana-if" too, but yeah, this is cleaner)

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@kimjoar
Copy link
Contributor Author

kimjoar commented Feb 7, 2018

Btw, here's a tiny Kibana plugin I created using the plugin-helpers changes (elastic/kibana-plugin-helpers#57) that relies on @kbn/datemath:
my-kbn-plugin-0.0.0.zip

First build Kibana (yarn build --skip-archives --skip-os-packages), then cd into build/kibana-... for your architecture, then run:

./bin/kibana-plugin install file:./path/to/my-kbn-plugin-0.0.0.zip

and you should see something like this in the output when starting the Kibana server:

{ units: [ 'y', 'M', 'w', 'd', 'h', 'm', 's', 'ms' ] }

(you'll see it during optimize after plugin install, as optimize starts the kibana server)

EDIT: updated zip, should now log at startup on server, when the api endpoint is hit, and when opening the plugin in the ui.

@azasypkin
Copy link
Member

Btw, here's a tiny Kibana plugin I created using the plugin-helpers changes that relies on @kbn/datemath: my-kbn-plugin-0.0.0.zip

Ah, nice! I was about to ask you how to test install part :)

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@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.

Haven't noticed any issues while running Kibana and installing of the example plugin, LGTM

// e.g. imports resolve properly. If we don't build the packages here, the
// `main` field in their `package.json` would link to a location that
// doesn't exist yet.
'buildPackages',
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is no longer needed because of the change to kbn bootstrap (it runs kbn:bootstrap scripts defined in package.json in all packages)

Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

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

LGTM

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@kimjoar kimjoar force-pushed the platform/import-datemath branch 2 times, most recently from 284ffe9 to 368664b Compare February 8, 2018 14:11
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@kimjoar kimjoar force-pushed the platform/import-datemath branch from f9ced51 to 3a92092 Compare February 8, 2018 14:19
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

{
"presets": [["env", {
"targets": {
"node": "6.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

We should use node: current rather than pinning to node 6

},
"devDependencies": {
"babel-cli": "^6.26.0",
"babel-core": "^6.26.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

babel-core isn't necessary

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@@ -0,0 +1,20 @@
{
"name": "@kbn/datemath",
"version": "5.0.0",
Copy link
Contributor

@epixa epixa Feb 12, 2018

Choose a reason for hiding this comment

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

We shouldn't need to version this. We should only even need to include a license if it's forked from a separate project (which this particular package is).

Copy link
Contributor Author

@kimjoar kimjoar Feb 12, 2018

Choose a reason for hiding this comment

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

Haha, I'm sooo used to npm complaining that I've added because of that. But yarn isn't complaining about missing version, so I'll 🔥 it

Copy link
Contributor

Choose a reason for hiding this comment

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

Npm wouldn't complain either because this package is marked as private, which disables pretty much all of the npm integrity checks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Aaand it's a no-go:

18:35:14 Installing dependencies in [kibana]:
18:35:14 
18:35:15 $ node ./preinstall_check
18:35:15 [1/5] Validating package.json...
18:35:15 [2/5] Resolving packages...
18:35:15 error Package "@kbn/datemath@" doesn't have a "version".
18:35:15 info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Copy link
Contributor

Choose a reason for hiding this comment

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

What? Why on earth would it do that? Maintaining versions on these packages doesn't make any sense, and it's definitely going to get out of date really fast. I'd argue it's out of date the moment it is contributed to the project :P

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why? I expect because link: and private: true are edge-cases.

Copy link
Contributor

@w33ble w33ble Feb 13, 2018

Choose a reason for hiding this comment

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

Just curious, and this seems like a decent place to ask; why not just pin all the package versions to the Kibana version in the root, ala lerna's default behavior (ie. not independent mode)? They're all technically new packages, so it's not like we'd be rolling back versions or anything. And they're all pretty hard-bound to Kibana anyway... and we're also not publishing any of them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

++ I've been thinking about the same thing. We could write some tooling in yarn kbn to handle it. It could require exact version match on all private: true packages, for example. That way we could still have publishable packages, if we want to (not sure we do want that any more, though, so it might not be necessary at all and we just require exact same version on every package)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, that's what I was thinking too. A kbn version, similar to npm version (or I assume lerna, I've only used lerna with independent versioning so far) that would just pump core and all the packages with it.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@kimjoar kimjoar merged commit 1c3b404 into elastic:master Feb 13, 2018
@kimjoar kimjoar changed the title Production package example: datemath Move @elastic/datemath into monorepo Feb 13, 2018
kimjoar added a commit to kimjoar/kibana that referenced this pull request Feb 13, 2018
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@kimjoar kimjoar deleted the platform/import-datemath branch April 18, 2018 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v6.3.0 v7.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants