Preserve directive prologues fixes #5 #7

[blutorange]

This fixes #5 and also includes the fix for #7 since I need it for this. While the relevance of strict directives may be doubtful for modules, correctness is still a goal and we should still preserve the original code and only order imports.

For references, this code

// below is a directive prologue
  'use custom' ; /* more directives... */ 'enable typecheck'
                 'forbid IE'

import './SetupEnvironment';
import type { Period } from './Period'

"this is not a directive prologue";

function foo() {
}

now becomes

// below is a directive prologue
"use custom";
/* more directives... */

"enable typecheck";
"forbid IE";

import "./SetupEnvironment";

import type { Period } from "./Period";

("this is not a directive prologue");

function foo() {}

and the following

; 'use strict'

import './SetupEnvironment';
import type { Period } from './Period'

"this is not a directive prologue";

function foo() {
}

still becomes

import "./SetupEnvironment";

import type { Period } from "./Period";

("use strict");

("this is not a directive prologue");

function foo() {}

since an empty statement is not a directive prologue according to the spec.

[IanVS]

I can't give this a thorough review right now, but I wonder, is there a way to check if there is a performance impact to this change?

[blutorange]

We could of course do it manually, not sure if we can add performance tests. But regarding how it "should" affect the performance:

• Preserving directive prologues should not affect it all all, since I'm only using the result from the parse that's already being done
• Other than that, I only changed how the imports are removed from the code. Before, a Regex was created for each import, then run in the code. Now, I build a list of ranges to replace (which calls sort on the list of ranges, but that's around O(n log n) and the input size is only the number of imports present in the file), do a bunch of substrings to extract the parts to keep, then join those parts back together.

So I wouldn't expect this to have an effect on performance (if anything it could improve it due to less Regexes). But perhaps we should take a large JS file and compare the times it takes to format, just so we can rule out an unexpected bottleneck.

[blutorange]

@IanVS Do you have time to take a look at this in the next few days? Otherwise do you mind if I do a quick test myself and then merge?

[IanVS]

I'll give it a quick glance through today and approve. Curious about perf, but I don't think that's a blocker.

[IanVS]

@blutorange In reading the spec, I see that it says:

A Directive Prologue may be an empty sequence.

I'm not so familiar with the spec, is an empty sequence different from an empty statement? I guess an empty sequence is ""?

[blutorange]

@IanVS As far as I understand it

A Directive Prologue is the longest sequence of ExpressionStatements [...] where each ExpressionStatement in the sequence consists entirely of a StringLiteral token followed by a semicolon.

An empty sequence is like the empty set, so that's just their way of saying that having the directive prologue is optional.

This is a source file with an empty directive prologue list, consisting of an empty statement and a function declaration statement.

;
function foo() {}

This is a source file with a single-element directive sequence, and the value of the directive is the empty string.

"";
function foo() {}

This is also source file with a single-element directive sequence. (The semicolon is inserted via the process of automatic semicolon insertion)

""
function foo() {}

It doesn't really matter though, since we aren't doing the parsing ourselves and just rely on the parser being implemented correctly. I just added some tests for these cases just in case somebody gets the idea to implement the parsing manually ; )

PS: You can use e.g. https://astexplorer.net/ to see how a piece of code parses.

[IanVS]

I tested this out in my own project, and it seems to make no difference in performance, prettier takes roughly 14.5 seconds to check the formatting either way, and I did not get any formatting problems when running this branch. Nicely done!

[IanVS]

These comments are helpful, thanks.

[IanVS]

😍

[blutorange]

Yeah, I've come to the realization that otherwise even I myself won't understand what's going on when I look at code weeks or months later ; )