-
Notifications
You must be signed in to change notification settings - Fork 17
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
Tighten .npmignore ; use babel as transpiler #1
Conversation
Thanks for the PR! I'll review it and give you my feedback asap. |
Babel is a transpiler, it produces files in plain Javascript so that users of the library don't need to support the same language level - that lets the library use features the language doesn't normally have, e.g. I saw this package does have babel at As a consequence the current "lib" file has a baked in copy of |
Yes, I guess I just wanted to understand precisely what problem this PR is solving. I understand the "how", not the "why":
Based on that I'll be better able to assess what I want to keep from the PR :) |
btw, agreed that the e2e don't run the current version but rather the version present in e2e/node_modules. I did that on purpose so that I could not only test the code but also ensure that my package.json is properly configured. It's the closest thing to ensuring that the published module works as intended. I agree though that the prepublish task doesn't make much sense anymore, I should probably update it to npm pack/npm install the current version of the library before running the tests |
The first why, and wanting nice things to exist, and wanting to learn something. We have tried to settle on a standard for our packages internally and the best way to know I'm wrong is to be confident about something on the internet ;) How I got here: I did something similar as a POC, it seems to have worked, then I thought I'd try use a community standard solution and I found Re tests - it's a pain to have tests as a separate project, our setup is just a test folder and |
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.
Thanks for the suggested change.
I liked that the project was standalone and didn't make any assumption on the presence of a build tool but as you said it's probably unnecessary as most react projects will have one anyway. The resulting lib and npm package are much cleaner, so it's a change for good.
I left 3 minor comments on your PR, can you take a look? I'll release a v2.0.0 when your PR is merged.
.npmignore
Outdated
@@ -0,0 +1,5 @@ | |||
# Ignore everything |
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.
thanks for introducing the .npmignore. Since the configuration is self explanatory the comments don't seem necessary, could you remove them?
src/index.js
Outdated
@@ -1,5 +1,5 @@ | |||
import React, { Component } from 'react'; | |||
import debounce from 'lodash.debounce'; | |||
import {debounce} from 'lodash'; |
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.
could you add spaces inside {} for consistency? { debounce }
.npmignore
Outdated
@@ -0,0 +1,5 @@ | |||
# Ignore everything | |||
* | |||
.* |
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.
why is .* necessary since we already have *? can it be removed?
Done! I've accidentally signed the commit with my twin brother's account, let me know if it matters and I'll try to undo it. |
no worries about the commit author, the more the merrier. thanks a lot for your contribution! |
Thanks for the package! We have a problem of an expensive component with an svg, that we'd like to redraw asynchronously, with an extra state change after the rest of our components are already in place, and this package addresses it.
This change proposes to use Babel to create the lib/index.js instead of webpack.
The resulting file is quite short, I am pasting it below - for comparison, the current webpack output has 576 lines.
It expects the client of the package to have a build process involving something like
webpack
that will understand what to do with e.g. require('react'), but it's a fairly safe assumption for react projects.I've ran the tests and they passed but I had to locally make a following change:
otherwise the tested code wasn't the newest version :)
Here's how the output looks like: