Skip to content

Optional configuration for multiple imports per line and strictly one import per line. #50

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

Merged
merged 6 commits into from
Feb 26, 2018

Conversation

shobhitg
Copy link
Contributor

@shobhitg shobhitg commented Feb 6, 2018

As per buehler/typescript-hero/issues/379, there should be an option
multiLineWrapMethod, where a user can choose between:
ONE_IMPORT_PER_LINE
OR
MULTIPLE_IMPORTS_PER_LINE

Shobhit Gupta added 2 commits February 5, 2018 22:02
As per buehler/typescript-hero/issues/379, there should be an option
`multiLineWrapMethod`, where a user can choose between:
`ONE_IMPORT_PER_LINE`
OR
`MULTIPLE_IMPORTS_PER_LINE`
@shobhitg
Copy link
Contributor Author

shobhitg commented Feb 6, 2018

This change will provide code generation support from typescript-parser.
I will make another change in typescript-hero to use this facility.

But I am not sure how to push it in since I have another pending change request.

@shobhitg
Copy link
Contributor Author

shobhitg commented Feb 6, 2018

Once typescript-hero consumes this change, this it will also fix buehler/typescript-hero/issues/358

Copy link
Owner

@buehler buehler left a comment

Choose a reason for hiding this comment

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

Cool idea! And many many thanks for your work. I reviewed it, and I'd suggest some small changes as documented. After that, we're good to go.

@@ -45,7 +46,8 @@
"typedoc": "^0.9.0"
},
"dependencies": {
"lodash": "^4.17.4",
"lodash": "^4.17.5",
Copy link
Owner

Choose a reason for hiding this comment

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

so if you want to use lodash-es instead of lodash (which is fine by me, since I didn't knew it existed) you can remove the other one right? or are both needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Both are needed, I only had to add these because I was facing errors in running npm run develop. Right now lodash imports are untouched. At some point I would change those imports to use lodash-es. With that I tihnk we can eventually get treeshaking benefit.

Copy link
Owner

Choose a reason for hiding this comment

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

Alright

* @type {'MULTIPLE_IMPORTS_PER_LINE' | 'ONE_IMPORT_PER_LINE'}
* @memberof TypescriptGenerationOptions
*/
multiLineWrapMethod: 'ONE_IMPORT_PER_LINE' | 'MULTIPLE_IMPORTS_PER_LINE';
Copy link
Owner

Choose a reason for hiding this comment

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

I'd use a string enum for this particular case:
This way, it should be exported and is easy extendable (and more convenient to use in an IDE)

export enum MultiLineImportRule {
  onePerLine = 'onePerLine',
  multiplePerLine = 'multiplePerLine',
}

With this method, we can implement this feature as a normal config in typescript hero and use the enum directly (as string value)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good.

getImportSpecifiers(imp, spaceBraces),
lib,
);
let retVal:string = '';
Copy link
Owner

Choose a reason for hiding this comment

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

missing space in code formatting

Copy link
Owner

Choose a reason for hiding this comment

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

And please use the whole name returnValue or generatedImport or something like that. I'm not a big fan of abbreviations since we're not coding C or something ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yup.


if (importString.length > multiLineWrapThreshold) {
if (specifiers.length > multiLineWrapThreshold) {
Copy link
Owner

Choose a reason for hiding this comment

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

This actually changes the behaviour of the multi line wrap threshold. before, the generated string was checked for his length. Now only the specifiers.

Or did I misread something?

Copy link
Owner

Choose a reason for hiding this comment

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

It should behave like before, or we need to introduce a BREAKING CHANGE

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 actually intended this change, because I thought that it is the right thing to do, didn't realize that it could be considered a Breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, I will rever that part for now. Its small thing to change later if think that it should be done.

const sortedImportSpecifiers: SymbolSpecifier[] = imp.specifiers.sort(specifierSort);
let importSpecifierStrings: string = '';

if (multiLineWrapMethod === 'MULTIPLE_IMPORTS_PER_LINE') {
Copy link
Owner

Choose a reason for hiding this comment

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

Please use the string enum, as mentioned above

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes.

@@ -7,7 +7,7 @@
"outDir": "../build",
"rootDir": "../src",
"declaration": true,
"sourceMap": false,
"sourceMap": true,
Copy link
Owner

Choose a reason for hiding this comment

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

Please not in the base config. The tsconfig.jsonconfiguration does specify sourceMap: true. The base should not change that since the production config does not overwrite the setting again.

-> false

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

@buehler
Copy link
Owner

buehler commented Feb 6, 2018

To consume the change, we will release the parser and then we can update it in typescript hero. Afterwards the settings needs to be coded in TSH

@shobhitg
Copy link
Contributor Author

shobhitg commented Feb 6, 2018

I think there are some inefficiencies in this file in general. There is some logic we are doing more an once.
I will take some time to re-think and refactor the code.
Also, I will keep buehler/typescript-hero/issues/397 in mind.

@buehler
Copy link
Owner

buehler commented Feb 6, 2018

Thank you so much 🙇
I'm currently implementing tests for typescript hero.

@shobhitg
Copy link
Contributor Author

I have made some changes as per what I think are the best set of options.

But I am not very good with tests, I just updated them using the test script.

@buehler Please review and let me know if anything needs improvement, and also see if you can help with tests.

@shobhitg
Copy link
Contributor Author

Just FIY, the option oneImportPerLineOnlyAfterThreshold should be default in ts-hero as per legacy behavior.

@shobhitg shobhitg changed the title Optional configuration for multiple imports per line Optional configuration for multiple imports per line and strictly one import per line. Feb 11, 2018
@shobhitg
Copy link
Contributor Author

Option strictlyOneImportPerLine will take care of buehler/typescript-hero/issues/351

@shobhitg
Copy link
Contributor Author

@buehler Can you please review this? Once we are settled with this change, then I would need to make a parallel ts-hero change to make it work with this commit, and once that is reviewed, both can go in together.

@buehler buehler merged commit f8f72f4 into buehler:develop Feb 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants