Currently, prettier.format returns an error when invalid syntax is parsed. This crashes the plugin.

Fixing this should be as simple as adding a try-catch around that block.

It would be great if we could optionally specify a flag, such as warn: True that will use console.warn to warn the user of compilation errors too, instead of just silently failing.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

The test "throws on invalid prettier config options" at __tests__/index.js#L120 fails, even though it throws the exact error we expect to catch. Why aren't we catching this?

I.e , which node version is required for this plugin?

It would be ideal if we could match compatibility with Webpack 2.

I'm using the Webpack's node.js compiler api to prettify and bundle some code that contains syntax errors (on purpose). Instead of getting the compilation or prettifier errors on the stats.toString() my entire programs stops running and the webpack's compiler.run callback never gets triggered.

    const compiler = webpack(webpackConfig);
    compiler.run((err, stats) => {
        //this line of code never runs
        if (err) {
            console.error(err);
            return;
        }
   
        // i should get the compilation error information here, after all its just a syntax error
        if(stats.hasErrors()) console.log("compilation errors: "+stats.toString());
        else console.log("compilation success");
    });

This is my Prettier-webpack-plugin configuration:

  plugins: [
    new PrettierPlugin({
        parser: "babylon"
    })
  ]

This is the code I'm trying to compile with errors

:

This is the exception I get on the console:

• Manually check tests since travis is pitching a fit
• Publish as minor version bump due to raising prettier error

I really like what the folks behind All Contributors are doing, so I'd like to bring that into this project, too. What we can't afford to pay in money we can at least reward with respect 😃

Prettier's API now has information regarding which extensions are available for processing, so we should really just use this now: https://prettier.io/docs/en/api.html#prettiergetsupportinfo-version

I hate to say this on my most popular project, but I unfortunately no longer have a use for this project personally now that I'm out of college and no longer using this in group projects.

I would like to either deprecate the project or add new collaborators to help maintain it, since I won't be putting much work into this anymore.

Maintaining this is fairly easy and offers some webpack learning opportunities - basically just update Prettier and their options, and fit Webpack's ever-evolving API, at least with regards to plugins (and optionally loaders.

I'll leave this one up for a hot minute, so if you'd like to take this project under your wing just comment below. Otherwise, I'll deprecate the project and suggest alternative methods for prettifying your code collaboratively.

I can't do this on the computer I'm using right now, so this is a note for me to update all contribs next time I'm on a dev machine:

pastellnc: code
nicolasbeauvais: code
alesanchezr: code, bug

npm ERR! Could not resolve dependency:
npm ERR! peer prettier@"^1.0.0" from [email protected]

actual version of prettier is 2.2.1

Prettier has made some awesome stride lately, including support for these languages:

• CSS
• TypeScript
• GraphQL

I'd like to change defaults for the next version to include the common file extensions for these files.

Something as simple as a greenkeeper bot would probably be enough, but we also need to make new releases and change default extensions and such when necessary. So the greenkeeper PRs are more of a "hey its time to make sure we're up to date" rather than just merge and release.

Currently, the plugin rewrites files just a bit too late, so the bundler runs twice in watch mode. Once on the file changes by user, a second time when the plugin reformats the file.

It would be great if we could manage to rewrite the file before the bundler finalizes the assets, that way code is only bundled once in watch mode.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

I seem to recall webpack 4 coming out with a new API for plugins, so this will be a non-trivial task but a necessary one.

Fixes #27

I wrote the bulk of this when I should have been in a class's test study session, so I neglected proper tests.

Currently, tests utilize existing global installs of webpack, prettier; this means tests may result in different outcomes across different systems.

So, I think its best if the project move to testing via a tool like Jest.

To do this:

• First raise package.json, README.md to the root directory from /src

Then, the test suite should:

• Involve Webpack in some manner other than a dependency on the published module
  • Would a peerDependency be suitable? Or a test-suite specific package.json to version Webpack for the tests?
• Utilize Webpack's programmatic API to test against some defined configurations and compare the initial sources vs modified sources

Are there any options or future plans to include options to exclude files from certain directories (e.g. node_modules), or perhaps to only include files from certain directories?

Not sure why, but Travis CI tests are failing due to yarn reporting 404 for different packages each time. Seems like a bug, possibly related to updating our dependencies? Need to look into this as it makes merging/publishing dangerous, not knowing if tests are affected.