-
-
Notifications
You must be signed in to change notification settings - Fork 242
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
v2 Refactor #86
v2 Refactor #86
Conversation
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
@omnidan Looks like you need to remove Circle CI from trying to build this repository. |
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
@Richienb I removed Circle CI. However, Travis is failing as well due to code style problems. Please adjust the code style according to the current standard or switch to http://standardjs.com, similarly to what omnidan/redux-undo uses. |
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
@Richienb thanks! CI is passing now! can you please check if we really need These two packages seem to be GPL-3.0 licensed (according to fossa), which might "infect" our package with GPL-3.0 as well and discourage people from using it. |
@omnidan It's not. Those packages are licensed under Apache 2.0 which allows distribution under MIT as long as we reference them which I'm pretty sure is done "automatically" via |
@Richienb alright, it might be fossa not detecting the license properly then. If they are Apache licensed it should be fine. |
I have resolved the issues manually on fossa, I think it will update on the next commit |
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
…cores Signed-off-by: Richie Bendall <richiebendall@gmail.com>
In v2, we've switched to using the official Unicode emoji names from https://unicode.org/Public/emoji/12.0/emoji-test.txt however, we could follow another list if need be. |
Just putting my 2 cents in regarding this refactor. I feel as though the use of lodash is unnecessary as it's use in this refactor can be replaced by simple native methods. Though it may not make much of a difference when it comes down to performance, I personally don't see the need to use an external library for things that can already be done easily using native JavaScript. Additionally, is the CLI implementation in v2 really needed? I feel as though it's inclusion somewhat takes away from it being a simple library that provides emoji support for Node.js projects. Though usable, I feel most people who would download the package would not end up using it for its CLI component, and even if they did want what that provides it could be easily implemented anyways. Other than that, good work on the refactor! |
… native methods. Signed-off-by: Richie Bendall <richiebendall@gmail.com>
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.
Very fast code response to my suggestion! Looks good to me 👍
It doesn't look like emoji.json is being pushed to this v2 branch. Might want to look into that @Richienb. |
@ShadowRanger emoji.json as in https://www.npmjs.com/package/emoji.json |
The current version of this library comes with an emoji.json (https://github.com/omnidan/node-emoji/blob/master/lib/emoji.json) file, containing all of the data for the available emojis that the library can access. Your refactor seems to be missing this, and is requiring a non-existent file (https://github.com/omnidan/node-emoji/blob/v2/index.js#L5). How you want to implement this file is entirely up to you. You could add it to the library itself like is done in the current version, or you could use a dependency specifically for it like the one you linked. Just be sure that the library accesses the JSON data correctly. Let me know if you would like me to elaborate on anything I have said, or if you have any trouble with it. Happy to help. |
@ShadowRanger I'm actually requiring the npm module called |
@Richienb My bad! I completely missed that. I have no idea how I did not see that in the package.json. I could have sworn that I checked first last night, clearly I did not have a clear state of mind at the time. My apologies! |
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Mind if I ask, what's the state of this PR? |
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
Signed-off-by: Richie Bendall <richiebendall@gmail.com>
We're almost there. Just gotta do some cleanup. |
What is the tradeoff we are willing to make in terms of dependencies vs extra code? |
@Richienb it depends. If we only use one or two functions and the library is huge, I would rather add the extra code. I think in general node-emoji is so simple that we should try not to use dependencies if possible. |
In this case, we're using lots of really small dependencies. |
"main": "index.js", | ||
"files": [ | ||
"index.js", | ||
"index.d.ts" |
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.
IME the three best ways to have TypeScript support are:
- Write the original package in TypeScript
- Include
.d.ts
files and tests in the repository - Defer to DefinitelyTyped for typings
Including raw .d.ts
files in this source repo but not testing them means contributors+maintainers will all have to manually check them. That's kind of hard if you're not TypeScript-familiar yourself -- and if you are, then why not write in TypeScript? 😜
Proposal: remove index.d.ts
and file a followup to discuss either rewriting in TypeScript or moving to DefinitelyTyped?
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'm for rewriting it in TypeScript if you are up for it - that would definitely be the best solution 😁
@@ -0,0 +1,288 @@ | |||
# Common settings that generally should always be used with your language specific settings |
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 haven't seen many repos include all these settings -.gitattributes
, .gitignore
, .. -- are they necessary in this PR?
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 agree, we should only have necessary files, maybe @Richienb can elaborate a bit?
|
||
[*.yml] | ||
indent_style = space | ||
indent_size = 2 |
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.
Does changing the formatting engine need to be in this PR? Seems like it's adding a lot.
Proposal: split it out so I can evangelize Prettier? 😄
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.
Personally a fan of prettier as well, so I'm fine with doing it in a separate PR with prettier! 💅
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 mean, I am personally up for it - so our editors know what way to follow.
node_js: | ||
- "0.10" | ||
- "lts/*" | ||
- "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.
Doesn't have to be in this PR, but just dropping a note - I'm down to switch over to GitHub Actions. Haven't seen a .travis.yml
update that wasn't a removal in quite a while 😄
}, | ||
"scripts": { | ||
"lint": "standard", | ||
"test": "standard && ava", |
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.
"test": "standard && ava", | |
"test": "ava", |
Also, out of curiosity: any reason for ava
? Nothing against it; I just haven't seen many projects using 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.
I think back then I had some issues with jest
, which was a loooong time ago though. I think now jest
would be the more standard and stable solution for this 🃏
|
||
Get an emoji name from an emoji. | ||
|
||
#### emoji |
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's an accessibility oddity to have headings with the same name (and also linking then only works for one). Should look at getting each of these unique text values...
const { assert } = is | ||
|
||
const emojiData = Object.entries(require('emojilib').lib).map(([name, { char: emoji }]) => [name, emoji]) |
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 personally find it confusing to have require
s nested within other statements. It'll also be harder to convert this to ESM if & when the time comes.
|
||
## Installation | ||
To install `node-emoji`, you need [node.js](http://nodejs.org/) and [npm](https://github.com/npm/npm#super-easy-install). :rocket: | ||
## Usage |
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.
Now that emojis are being sourced from other libraries, it'd probably be good to link to those libraries in the README.md.
"index.d.ts" | ||
], | ||
"engines": { | ||
"node": ">=10" |
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.
"node": ">=10" | |
"node": ">=14" |
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.
any reason why we should support 14 and higher only?
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.
Node 12 is now only in maintenance, and 14 is LTS. I suppose 12 would work too 🙂 but newer Node versions mean we can go with newer JS syntax.
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 say better keep it on 10 unless it's really needed, or the new additions are just great enough to justify the compatibility breakage.
##### removeSpaces | ||
|
||
Type: `boolean`\ | ||
Default: `true`. |
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've always found it confusing to have APIs that default a boolean parameter to true
when not provided. Can we call this:
##### removeSpaces | |
Type: `boolean`\ | |
Default: `true`. | |
##### preserveSpaces | |
Type: `boolean`\ | |
Default: `false`. |
} | ||
|
||
exports.find = emoji => { |
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.
Before there were *ByCode
and *ByName
equivalents for APIs such as .find
. Was it intentional to remove them in v2? (I can't find discussion)
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.
@omnidan thoughts?
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 would not know of a reason to remove them, maybe they were just forgotten about in the rewrite? /cc @Richienb
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.
Added them back in #113.
Signed-off-by: Richie Bendall richiebendall@gmail.com
Closes #55, Closes #57, Closes #62, Closes #66, Closes #77