Add more test cases. #502
Add more test cases. #502
Conversation
|
|
| "rules": { | ||
| "linebreak-style": "off", |
There was a problem hiding this comment.
eol should be set to \n. My bad for not setting it into the .vscode/settings.json or an .editorConfig file. I'll do it so this won't be an issue.
There was a problem hiding this comment.
My git is set to change the eol to CRLF when pull and LF when pushas I'm on Windows. The rule is colliding with that. There isn't going to be an issue if we disable the rule.
There was a problem hiding this comment.
I will upload a .gitattributes file so that won't be an issue for you anymore. I'm using autocrlf = input.
| @@ -1,5 +1,4 @@ | |||
| module.exports = { | |||
| exports.languages = { | |||
There was a problem hiding this comment.
There was a problem hiding this comment.
Sorry @JimiC but I still don't get the rationale here. Could you ellaborate this change?
There was a problem hiding this comment.
We aren't actually exporting a module per say, but a helper object, which falls into the category of the exports case.
There was a problem hiding this comment.
It's the same as we do with supportedExtensions, supportedFolders, defaultSchema.
There was a problem hiding this comment.
To be honest, I still don't see the point. As far as I know this is a matter of preference and its use will depend greatly on the way we're going to compose our module. Being this just the only export, I don't see this syntactic change as if it's bringing some benefit to the table.
The examples you reference are composed like that (in the case of supportedExtensions and supportedFolders) because when I first built the extension I thought that they were going to export more items. Finally they remained like that. No other reason behind it. In fact, I've thought of refactoring these modules for a long time but I've been a little bit careless with style in this project.
The way I see it, if I know my module is going to only export one item I don't like creating extra properties. It's like a default for ES5, in this case.
You see I may have also something in my inheritance that leans me towars bizantine discussions 😜
In order to close this, let's keep it this way for the sake of consistency as I myself haven't made it clear in the code.
There was a problem hiding this comment.
Do you want me to change every exports to module.exports? I can do that.
There was a problem hiding this comment.
No, no, don't worry @JimiC. I just wanted to understand why you decided to change this. I thought that maybe it was something that I was missing but now I see it's consistency or preference what was driving you.
There was a problem hiding this comment.
Yeah. Once again I failed to express myself clearly. 😞
| { icon: 'ng2_service_js', extensions: ['.service.js'], svg: true }, | ||
| { icon: 'ng2_module_ts', extensions: ['.module.ts'], svg: true }, | ||
| { icon: 'ng2_module_js', extensions: ['.module.js'], svg: true }, | ||
| { icon: 'ng2_component_ts', extensions: ['.component.ts'], filename: true, svg: true }, |
There was a problem hiding this comment.
This was already commented in another PR. Why the filename property?
There was a problem hiding this comment.
As mentioned in the other PR, will revise.
| @@ -144,7 +144,7 @@ exports.extensions = { | |||
| { icon: 'phpunit', extensions: ['phpunit.xml'], filename: true }, | |||
| { icon: 'plantuml', extensions: ['pu', 'plantuml', 'iuml', 'puml'] }, | |||
| { icon: 'procfile', extensions: ['procfile'], filename: true }, | |||
| { icon: 'prolog', extensions: ['P', 'pro'], languages: [languages.prolog] }, | |||
There was a problem hiding this comment.
LanguageIds can be added via plugins. In the case of Prolog you can find the extension here and if you see their contribution point you'll see that the id of prolog was correct.
|
OK, I figured it out. It was the damn |
This PR does the following:
icons.jsonis generated correctly.jarextension declaration.lodashusage where possible.