Feature/customizable tsfmt and prettier version #363

simschla · 2019-02-19T10:21:34Z

Providing a way to customize prettier/tsfmt versions.

This fixes #362

ammend initial

and fix changed formattings in tests for javascript (as well as replace deprecated parser)

nedtwigg

This looks great! I have a few nitpicks I left inline about keeping old methods around for back-compat, also a few other minor blips.

Only substantive feedback is update CHANGES and README.

lib/src/main/java/com/diffplug/spotless/npm/PrettierFormatterStep.java

plugin-gradle/src/main/java/com/diffplug/gradle/spotless/TypescriptExtension.java

lib/src/main/java/com/diffplug/spotless/npm/TsFmtFormatterStep.java

plugin-gradle/src/main/java/com/diffplug/gradle/spotless/TypescriptExtension.java

nedtwigg · 2019-02-19T18:25:02Z

plugin-gradle/src/test/java/com/diffplug/gradle/spotless/TypescriptExtensionTest.java

+		setFile("test.ts").toResource("npm/tsfmt/tsfmt/tsfmt.dirty");
+		gradleRunner().withArguments("--stacktrace", "spotlessApply").build();
+		assertFile("test.ts").sameAsResource("npm/tsfmt/tsfmt/tsfmt.clean");
+	}


Great tests!

- keeping backward compatibility - concise naming - provide javadoc to clarify not-self-explanatory methods

simschla · 2019-02-20T09:49:34Z

This looks great! I have a few nitpicks I left inline about keeping old methods around for back-compat, also a few other minor blips.

Only substantive feedback is update CHANGES and README.

Thanks for the feedback, I tried to integrate all the changes you requested. CHANGES and README will be updated ASAP.

simschla · 2019-02-21T16:33:58Z

CHANGES and README updated to reflect the changes.

nedtwigg · 2019-02-21T18:35:22Z

lib/src/main/java/com/diffplug/spotless/npm/TsFmtFormatterStep.java

+
+	public static final String NPM_PKG_TS = "typescriptVersion";
+
+	public static final String NPM_PKG_TSLINT = "tslintVersion";


Sorry, I think my feedback asking for these constants wasn't clear. I would expect that NPM_PKG_TSFMT would be equal to its npm package name, typescript-formatter. And the same for the other constants. The problem with the current approach is that there's no consistent mapping between the npm package name and the name that spotless is expecting. This gets even harder for users to debug because there's no error if you use an unexpected package name, it's just ignored silently.

If you use the actual npm package names, then the build file could look like this:

tsfmt([ 'typescript-formatter': '7.2.2', 'typescript': '2.9.2', 'tslint': '5.1.0'])

which would look very familiar to any user that has used npm. This also opens up an error-checking opportunity. What if the package.json just used the versions map as its devDependencies. Then users will have the option to add plugins if they want, and if they mistype a package name they'll get a loud descriptive error from npm about the unknown package.

Thanks for the clarifications!

If you use the actual npm package names, then the build file could look like this

That would make it really look like the package.json. One caveat of this would be, that we can no longer profit on the groovy goodness of named parameters.

The method public TypescriptFormatExtension tsfmt(String formatterVersion, String typescriptVersion, String tslintVersion) and public TypescriptFormatExtension tsfmt(Map<String, String> versions) would no longer look similar in calling:

tsfmt(['typescript-formatter': '7.2.2', 'typescript': '2.9.2']) // vs tsfmt(typescriptFormatter: '7.2.2', typescript: '2.9.2')

The Problem I see there is the hyphen-case in typescript-formatter. So if we go this way, we might have to drop the tsfmt(String formatterVersion, String typescriptVersion, String tslintVersion) method overload and only provide the map signature. Opinions?

This gets even harder for users to debug because there's no error if you use an unexpected package name, it's just ignored silently.

That, however, we could address by checking contents of the map keys vor validity.

What if the package.json just used the versions map as its devDependencies. Then users will have the option to add plugins if they want

Although this seems convenient, it might be very maintenance intensive - we will not be able to check the system with all combinations and plugins and therefore cannot guarantee any "this combination works" labels. (And we will probably not be able to help out users who try any combination of versions and plugins and do not succeed).

(I for myself tried getting prettier to run with the java plugin but had no success since the plugin was not compatible with the j2v8 runtime at the time of trying.)

How do you suggest going forward?

So if we go this way, we might have to drop the tsfmt(String formatterVersion, String typescriptVersion, String tslintVersion) method overload and only provide the map signature. Opinions?

That's one less method to document and maintain. Further, there's no chance a user can use this method without A) looking up the latest package version on NPM and B) looking up the spotless-specific name for that particular package, which is different for each package. If we adopt the "map as devDependencies plus defaults", then all the user needs to know is "this map becomes your npm deps, plus these default packages and versions if you don't specify them". Less for us to document, less for us to maintain, same easy defaults for most users, more flexibility for power users.

That, however, we could address by checking contents of the map keys for validity.

Yup. I'm fine with this, and it's easy to do. But it's not as easy as dumping this job onto npm, and npm is going to redo that check again anyway.

it might be maintenance intensive - we will not be able to check the system with all combinations and plugins and therefore cannot guarantee any "this combination works" labels

By allowing users to specify versions for the 3 packages, we're already opening ourselves up to that. So long as the defaults work out of the box, I think it's fine if users discuss amongst themselves "these versions don't work" on our issues page.

It's true that by giving users power, we increase the chance that they raise issues. I think it's important to see those issues as something interesting you have the choice to engage with, but not as a responsibility. Your contribution of tsfmt and prettier was a huge and valuable donation of your time, you didn't owe it to anybody but you did it anyway. This PR is this same. And if users have questions about incompatible combos in the future, it might be a chance to learn about an interesting new prettier plugin. But definitely don't take them as your responsibility. The issues are a public forum, it's fine for them to stay open without a response.

…rsion

…mmit removes it.

…ough map.

nedtwigg · 2019-03-11T05:15:14Z

@simschla Whaddya think of this direct-passthrough approach? It looks about as easy to use, but we get the advantage that npm is doing error-checking for us, and power users can use plugins and their own forks of npm packages.

…or the new map syntax.

…o recommend them in the README.

…rsion in the test, but npm gave a nice error message.

…rsion

simschla · 2019-03-12T11:53:26Z

Thanks for stepping in since I wasn't able to get back to this the last 2 weeks...

The current state LGTM. One improvement we could make is making sure, that at least the required packages are specified when using the map-approach (especially for tsfmt -> that way one cannot 'forget' to specify the tslint-version for example...). What do you think?

nedtwigg · 2019-03-12T11:58:20Z

Only issue is if I want to use my-tslint-pkg, rather than the official one. Not a common usecase, but if you are missing some packages you get a pretty loud error.

simschla · 2019-03-12T13:32:55Z

Only issue is if I want to use my-tslint-pkg, rather than the official one. Not a common usecase, but if you are missing some packages you get a pretty loud error.

Didn't think of that, but makes sense, yes. So then, I don't see why we shouldn't merge this :-)

simschla added 5 commits February 19, 2019 11:18

adding support for customizing prettier/tsfmt verisons

8b51a9e

ammend initial

bumping prettier (default) version to 1.16.4

c28420a

and fix changed formattings in tests for javascript (as well as replace deprecated parser)

adding test to verify yaml formatting works

c92a6fa

bumping typescript/tslint default version numbers

f698b2c

adding integration tests for custom tsfmt versions

94dc878

nedtwigg requested changes Feb 19, 2019

View reviewed changes

integrating PR feedback

39e9796

- keeping backward compatibility - concise naming - provide javadoc to clarify not-self-explanatory methods

nedtwigg reviewed Feb 21, 2019

View reviewed changes

updating documentation for custom tsfmt/prettier versions

d96245b

simschla force-pushed the feature/customizable-tsfmt-and-prettier-version branch from cb661b7 to d96245b Compare February 22, 2019 06:44

nedtwigg added 3 commits March 10, 2019 15:56

Merge branch 'master' into feature/customizable-tsfmt-and-prettier-ve…

6720dc6

…rsion

TsFmtFormatterStep had a "baseDir" variable which was unused. This co…

ef1c5c3

…mmit removes it.

Updated prettier and tsfmt to specify their versions using a pass-thr…

24f6b6b

…ough map.

nedtwigg approved these changes Mar 11, 2019

View reviewed changes

nedtwigg added 5 commits March 10, 2019 22:30

Fixed a bug in TypescriptExtension and updated the integration test f…

edeafb1

…or the new map syntax.

None of the prettier plugins actually work, so it's not a good idea t…

e577de5

…o recommend them in the README.

The downside and upside of the map approach! I forgot to specify a ve…

e5db0f8

…rsion in the test, but npm gave a nice error message.

Merge branch 'master' into feature/customizable-tsfmt-and-prettier-ve…

5d2063a

…rsion

Merge branch 'master' into feature/customizable-tsfmt-and-prettier-ve…

00b4096

…rsion

nedtwigg merged commit 9843130 into diffplug:master Mar 12, 2019

simschla deleted the feature/customizable-tsfmt-and-prettier-version branch June 2, 2020 14:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature/customizable tsfmt and prettier version #363

Feature/customizable tsfmt and prettier version #363

simschla commented Feb 19, 2019 •

edited

nedtwigg left a comment

nedtwigg Feb 19, 2019

simschla commented Feb 20, 2019

simschla commented Feb 21, 2019

nedtwigg Feb 21, 2019

simschla Feb 22, 2019

nedtwigg Feb 22, 2019

nedtwigg commented Mar 11, 2019

simschla commented Mar 12, 2019

nedtwigg commented Mar 12, 2019

simschla commented Mar 12, 2019


		public static final String NPM_PKG_TS = "typescriptVersion";

		public static final String NPM_PKG_TSLINT = "tslintVersion";

Feature/customizable tsfmt and prettier version #363

Feature/customizable tsfmt and prettier version #363

Conversation

simschla commented Feb 19, 2019 • edited

nedtwigg left a comment

Choose a reason for hiding this comment

nedtwigg Feb 19, 2019

Choose a reason for hiding this comment

simschla commented Feb 20, 2019

simschla commented Feb 21, 2019

nedtwigg Feb 21, 2019

Choose a reason for hiding this comment

simschla Feb 22, 2019

Choose a reason for hiding this comment

nedtwigg Feb 22, 2019

Choose a reason for hiding this comment

nedtwigg commented Mar 11, 2019

simschla commented Mar 12, 2019

nedtwigg commented Mar 12, 2019

simschla commented Mar 12, 2019

simschla commented Feb 19, 2019 •

edited