Prettier 1.9 keeps build-tool comments attached to their imports

A comment can participate in a build even though JavaScript itself ignores it. Webpack's chunk-name annotation is one example. Moving the comment away from an import expression can change what the build tool sees without changing the apparent JavaScript operation. Prettier 1.9 fixes a case where formatting an arrow function relocated precisely that kind of comment into the function's parameter list.

The December 5 release announcement includes this correction alongside JSX fragment support and TypeScript-specific fixes. The comment bug gives the release a useful technical angle. A formatter must preserve the relationship between source constructs and metadata that other tools consume, not merely produce text accepted by the JavaScript parser.

I consider predictable formatting useful in a web application, but its implementation must respect the surrounding toolchain. The source can carry information for a bundler or type checker as well as the runtime. Losing that information is a functional problem even when the resulting file still looks neatly arranged.

The enclosing node determines comment placement

The implementation review for the fix explains the error. A comment inside the parentheses of a call expression could receive an enclosing arrow-function node instead of the call-expression node. Subsequent argument handling then operated with the wrong context and relocated the comment.

The reported input includes an object property whose value is an arrow function returning import('./test' /* webpackChunkName: "test" */). Before the correction, formatting moves the annotation into the arrow function's empty parameter parentheses. The import remains, but the comment no longer sits at the module request it describes.

The fix preserves the original association. That is more informative than saying the release improves comment formatting, because the issue is which syntax node owns the comment. The formatter's internal representation needs enough context to distinguish a call's argument list from the enclosing arrow function's parameter list.

This is also why a runtime-only account of equivalence is insufficient for a source formatter. A build tool can assign meaning to a comment attached to a particular operation. The release announcement explicitly identifies broken behavior in tools such as Webpack as the consequence. Preserving source for a multi-tool pipeline requires accounting for that relationship.

TypeScript syntax needs its own printing rules

The release removes trailing commas after object rest when using the TypeScript parser. Its example destructures named properties and then collects the remainder with ...rest. The announcement says the previous output was inconsistent with JavaScript and Flow handling. The correction aligns the formatting of that construct across the supported parsers.

Another TypeScript fix restores parentheses around type assertions used as decorator expressions. The release's example is @(bind as ClassDecorator) above a class declaration. Previously, the formatter omitted the parentheses. Here the grouping is part of representing the expression in its syntactic context, so deleting punctuation is not simply a style preference.

Both fixes show why a formatter needs the language's actual syntax structure. A trailing comma permitted or preferred in one location is not automatically appropriate after every rest construct. An assertion expression can need parentheses in a decorator even when its tokens are familiar elsewhere. A single punctuation preference cannot substitute for those contextual rules.

JSX fragments become formatable source

Prettier 1.9 recognizes the new JSX fragment form, <>...</>. The release demonstrates a component returning several children inside a fragment. Formatter support lets that source participate in the same formatting workflow as other JSX, while the compiler and runtime still need their own compatible handling.

That separation matters when new syntax arrives across several tools. Accepting it in a compiler does not establish that an older formatter can parse it. A project that formats every changed file needs the formatter to understand the construct before its developers can use it throughout that workflow. This release removes that particular compatibility obstacle for fragments.

I find the comment and fragment changes related in that practical sense. Both concern the source moving through more than one tool. One preserves a bundler annotation at the right node, while the other lets newly supported syntax pass through the formatter at all.

Configuration entry points differ

The release adds EditorConfig support for indentation and maximum line length. Its CLI respects .editorconfig by default, with --no-editorconfig available to opt out. API consumers do not receive that behavior by default, because of possible editor-integration issues. An integration can opt in through editorconfig: true when resolving configuration.

Those defaults can explain differences between formatting from a command and formatting through an editor integration. The same formatter version does not guarantee the same resolved configuration when the entry points deliberately behave differently. The release also adds arrowParens, with avoid retaining the previous default and always requesting parentheses. Understanding which configuration was loaded remains necessary before attributing a changed result to the printer itself.