Skip to content
This repository has been archived by the owner on Mar 4, 2020. It is now read-only.

chore(mixed): fix imports and introduce bundler test #570

Merged
merged 18 commits into from
Dec 11, 2018

Conversation

layershifter
Copy link
Member

@layershifter layershifter commented Dec 6, 2018

This PR:


I also tested a build with Parcel manually, it works like a charm ⭐️

const classNames: ClassNamesFn

export default classNames
}
Copy link
Member Author

Choose a reason for hiding this comment

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

We decided to use custom typings for this module.

src/lib/colorUtils.ts Outdated Show resolved Hide resolved
@layershifter layershifter changed the title [WIP] chore(mixed): fix imports and introduce bundler test chore(mixed): fix imports and introduce bundler test Dec 7, 2018
@layershifter layershifter added 🚀 ready for review 🧰 fix Introduces fix for broken behavior. and removed 🚧 WIP labels Dec 7, 2018
CHANGELOG.md Outdated Show resolved Hide resolved
import resolve from 'rollup-plugin-node-resolve'
import commonjs from 'rollup-plugin-commonjs'

const lodashExports = [
Copy link
Member

Choose a reason for hiding this comment

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

(!) Missing exports
https://rollupjs.org/guide/en#error-name-is-not-exported-by-module-
node_modules/@stardust-ui/react/dist/es/components/Dropdown/Dropdown.js
pickBy is not exported by node_modules/lodash/lodash.js

How is this going to scale? Whenever a new function is used, do I need to remember I have to add it here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, it's a real problem 👎 lodash is CJS module, so the there is only one option.
If we will use Babel and babel-plugin-lodash this problem will gone.

Copy link
Member Author

Choose a reason for hiding this comment

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

Resolved with external and output.globals, now is much cleaner

build/gulp/tasks/test-projects.tsx Show resolved Hide resolved
logger(`✔️Source and bundler's config were created`)

await runIn(tmpDirectory)(`yarn rollup -c`)
logger(`✔️Example project was successfully built: ${tmpDirectory}`)
Copy link
Member

Choose a reason for hiding this comment

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

It seems we are ignoring rollup warnings. Are we ok with it or would we like to use this as an opportunity to tighten our rules and require warning-free build in rollup? (no warnings are currently allowed in webpack build)

Copy link
Member Author

Choose a reason for hiding this comment

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

I reworked it, now we have a warning whitelist, other warnings will throw.

We can fix all left circular imports in a separate PR because it will require more work.

@@ -58,6 +58,9 @@ jobs:
# - run:
Copy link
Contributor

@kuzhelov kuzhelov Dec 10, 2018

Choose a reason for hiding this comment

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

when we are planning to return this? And, actually, what was specific reason to disable these tests - currently we have no any checks that any client is able to consume our library

Copy link
Member Author

Choose a reason for hiding this comment

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

After #550 will be merged

@alinais alinais added this to layershifter in Core Team Dec 10, 2018
@@ -0,0 +1,110 @@
import replace from 'rollup-plugin-replace'
Copy link
Contributor

Choose a reason for hiding this comment

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

this should be placed somewhere under test-projects at the very least (we should create corresponding dir) - so that this client-oriented tests functionality will be cohesively structured

Copy link
Member Author

Choose a reason for hiding this comment

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

It's already placed in the separate dir. I don't want to be so specific for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, but the same reasoning would apply well in case it will be put in any dir - thus, I am not sure that this is a valid argument.

The reasoning behind my ask is the following: currently, with the dir introduced at the place where you are suggesting, we would have the following project structure:

/build/gulp
  /scaffold
  /tasks
       /test-projects

So, reasonable question is why scaffold directory is placed at this level of folder hierarchy? Is its content shared by any agents/tasks? The answer is "no" - the only place where it is used is test-projects module. Thus, I would suggest to put these bits to the module those belong to at the moment.

Copy link
Member Author

Choose a reason for hiding this comment

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

Is its content shared by any agents/tasks? The answer is "no" - the only place where it is used is test-projects module.

At now, yes. But in the future, I think that we will have other tasks that will should also have files and templates.

Copy link
Contributor

@mnajdova mnajdova Dec 11, 2018

Choose a reason for hiding this comment

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

I must agree here that better directory structure would reflect exactly what we test even. Having structure, something like:

/build/gulp
  /tasks
       /test-projects
         /cra-ts
         /parcel
         ...

will be much more cleaner, and it will be obvious what scenarios we got covered so far...

Copy link
Member Author

Choose a reason for hiding this comment

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

@kuzhelov @mnajdova you convinced me and I made these changes 👍

@@ -58,6 +58,9 @@ jobs:
# - run:
# name: Project Tests
# command: yarn test:projects:cra-ts
- run:
name: Bundler Tests
command: yarn test:bundlers:rollup
Copy link
Contributor

Choose a reason for hiding this comment

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

would suggest test:projects:rollup - as this won't introduce additional entropy and will still suggest that stack that client is using for her project

Copy link
Member Author

Choose a reason for hiding this comment

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

Moved into single entry, yarn test:projects 👍

# command: yarn test:projects:cra-ts
- run:
name: Project Tests
command: yarn test:projects
Copy link
Contributor

Choose a reason for hiding this comment

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

👍


task(
'test:projects',
series(
Copy link
Contributor

@kuzhelov kuzhelov Dec 10, 2018

Choose a reason for hiding this comment

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

actually, can we run them in parallel? It seems that there is no shared state between these tasks

Copy link
Member Author

Choose a reason for hiding this comment

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

I will left it as is for now. When this task will be enabled, we will able to test that it works in parallel. However, I almost sure that it will work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🧰 fix Introduces fix for broken behavior. ready for merge
Projects
No open projects
Core Team
  
layershifter
Development

Successfully merging this pull request may close these issues.

Impossible to build project with Parcel or Rollup
4 participants