Debugging Unibeautify in VSCode will not work 100% properly unless you disable code coverage while doing so. So we want to add `--coverage false to the launch args.

"args": ["--config", "jest.config.js", "--runInBand", "--coverage", "false"]

I have seen cases where adding a debugger statement triggered the debugger to stop, but not at the correct line. As a result, my standard practice is to turn coverage off during debugging, hence the "--coverage", "false" in the runtimeArgs parameter in launch.json

https://medium.com/@mtiller/debugging-with-typescript-jest-ts-jest-and-visual-studio-code-ef9ca8644132

This correctly doesn't apply beautification

// unibeautify:disable
function test() {
  console.log("test");
}

This does apply beautification

function test() {
  // unibeautify:disable
  console.log("test");
}

Hi,
Ask your goal is unify beatifier under one roof. And those beatifier would need code language as base. So I think your project would get many benefit from:
https://github.com/Microsoft/language-server-protocol

It already got support from Atom and other IDEs
I vision your project could become parts of this standard or become beatifier server protocol.

Good luck man

Hi,
I just want to know, is this projects works the same way as github.com/prettier/prettier ? Or they work differently?

See https://github.com/prettier/prettier/blob/fac08034e78f5eaf8ef3bbcb57d12893f84c3583/src/common/support.js

• Options
• Languages

We should start using ES6 over lodash when we can. Unfortunately not all of lodash's functions have a suitable alternative yet, but a good portion do. Ideally we want as fewer dependencies so the install is as small as possible.

_.filter(this.languages, (language: Language): boolean => can be replaced with something along the lines of this.languages.filter((language: Language): boolean =>.

_.map, _.filter, _.reduce all have ES6 equivalents.

https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore#quick-links
https://www.sitepoint.com/lodash-features-replace-es6/

Something I have been thinking about is that options management for a long time was a mess in Pretty Diff until I rewrote the architecture of the application around a centralized standard management of options internally. Even still options management in Atom Beautify was also kind of a mess in keeping up with various different beautifiers.

I am proposing a standard set of options with a central standard API. A stand alone code repository under the Unibeautify organization.

Here is what I am thinking in more detail:

• Options are defined in a central location to the Unibeautify project and not immediately associated with any particular beautifier (application agnostic).
• Options and the respective API are well documented.
• Each of the different beautifiers are free to decide which options they wish to consume/support. A beautifier is not required to support all available options.
• New options from a beautifier should not be added unless they are integrated into the central options management first.

Potential challenges

• We have to support the options that are already in the beautifiers and not do anything heavy handed that would break current support or backwards compatibility.
• We would have to win support from the various beautifiers.
• We would need to plan out a simple architecture that works for everybody.
• We would need living documentation that declares where the options are supported in the various beautifiers and in which IDE interfaces.

Goals

• Simplify maintenance and management as this application covers a wide spectrum horizontally and vertically.
• Announce innovation and capabilities from various competing beautifiers in a way other beautifiers and IDE maintainers can keep up with in a compatible way.
• Provide an additional layer of logical separation of concerns for Unibeautify.

• ignore-next-line - Ignore changes for next line
• disable and enable - Temporarily disable any changes until re-enabled
• ignore-line - Ignore changes for current line
• disable-beautifiers and enable-beautifiers - Temporarily disable any changes by beautifier(s) until re-enabled
• Only process if unibeautify: prefix is found in original text

See:

• https://prettier.io/docs/en/ignore.html
• https://palantir.github.io/tslint/usage/rule-flags/
• https://eslint.org/docs/user-guide/configuring.html#disabling-rules-with-inline-comments
• https://github.com/beautify-web/js-beautify/blob/d0924534cae2d024bfaefb4ab64a67d98c79e812/README.md#directives-to-ignore-or-preserve-sections-javascript-only

See https://travis-ci.org/Unibeautify/beautifier-eslint/jobs/346110253. Notice how the received output is missing a newline.

Expected value to be:

"console.log('hello world');
console.log('hello world');
"

Received:

 "console.log('hello world');
console.log('hello world');"

Well this could be THE killer feature, don't you think ?
Unless there's an add-on already doing that...

What do you think about unibeautify as the new name? This project will eventually support a Node.js API, CLI, Atom, and Sublime editor plugins.

Related to #58

See https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/executable.coffee#L418-L434

For Docker Executable it mounts the host’s root directory to an internal Docker directory
Then relatives all paths in arguments to that internal Docker directory

Does not fully support Whalebrew. Will fully support directly accessing via Docker.

When using Unibeautify as a dependency:

ERROR in [at-loader] ./node_modules/unibeautify/dist/src/beautifier.d.ts:549:21
    TS2693: 'Promise' only refers to a type, but is being used as a value here.

Hi,

I've tried to use unibeatify and prettydiff together in my react app.

Just imported unibeatify and beautifier-prettydiff but then I get this error:

import 'unibeautify';
import 'beautifier-prettydiff';

Error in ./~/sb-exec/lib/index.js
Module not found: 'child_process'

Thanks for your help!

See https://facebook.github.io/jest/docs/en/snapshot-testing.html

Perhaps there should be a utility to provide error handling. This utility can accept a title, message, and stack trace and format that information properly to the executing environment whether HTML, CLI, or one of the various IDEs.

• https://www.netlify.com/
• https://github.com/TypeStrong/typedoc

Pull Request previews will be helpful!

Add support for beautifiers with executables (port from Atom-Beautify)

See Glavin001/atom-beautify#1687

• Dependencies
  • Node
    • require (builtin)
    • requireg (global)
    • Project specific (local) (moved to #81 )
  • Executable
    • Configurable program path
    • Docker (moved to #80 )
• Error handling
  • Add the errors for the dependency to https://github.com/Unibeautify/unibeautify/blob/master/src/DependencyManager/Dependency.ts#L32

Any plan on supporting C++ in your CI? With clang-format the implementation should't be extremely tough.

The fileExtension is being passed as the filePath in the beautify function, which is obviously incorrect.

fileExtension is not supported by the BeautifierBeautifyData interface, so we can't pass that in.

https://github.com/Unibeautify/unibeautify/blob/master/src/beautifier.ts#L380

Related to #58

Beautifier Details
Name:
Link to project/homepage:

If this is a new beautifier, please fill out the below
Languages Supported:
How is it run (node, terminal, etc):

If this is to update an existing beautifier, please describe what should be updated

Additional context

For the documentation, Atom Beautify, and potentially other things it would be best to centralize the logic that matches languages, beautifiers, and options all together. The docs scripts do a lot of this already, but should be in core Unibeautify so it can be reused.

• List all loaded options (loadedOptions)
• List all supported options (getOptionsSupportedForLanguage?)
• List all loaded languages (getLoadedLanguages)
• List all supported languages (supportedLanguages)
• Get options supported by a beautifier for a language (getOptionsSupportedByBeautifierForLanguage)
• Get languages for beautifier (getLanguagesForBeautifier)
• Get languages supporting option (getLanguagesSupportingOption)
• Get beautifiers for a language (getBeautifiersForLanguage)
• Get beautifiers support for an option for a language (getBeautifiersSupportingOption)
• Get language based on Atom Grammar and file extension (findLanguages)

@Glavin001

@prettydiff - I'm interested in separating parsers from formatting rules (what we often call "beautifiers"), but at a more basic level I'd like to see a parsing framework that produces unified lossless parsed source trees.

Most parsers are optimized for speed, accuracy, and producing abstract syntax trees. This means they have source that is hard to read (because it does obtuse things to make it faster), they throw errors and halt on unknown syntax, and they discard whitespace and comments. All of these are bad beautifiers.

Parsers also do not interconnect or communicate - I can parse html and then parse the javascript inside the <script> tags, but the resulting parsed javascript tree is completely separate from the html tree. I could beautify each separately, but they can't interact. When we go to templating (mustache, php, braces for example), this gets really ugly. What we want is a framework of parsers that produce one syntax tree (or at very least one token stream with trees that can interact).

We have the ability to specify what options and what languages a beautifier supports, https://github.com/Unibeautify/beautifier-prettydiff/blob/master/src/index.ts#L10-L119, but no way to specify which options the beautifier supports for a specific language. Example: prettydiff supports the break_chained_methods option and the CSS language, but that option wouldn't be applicable to CSS, however with the way it's currently designed it does.

So need to design and implement a way to specify which options a language supports for each beautifier. Some ideas:

• CSS: true would mean the beautifier supports CSS and all of the beautifiers supported options are applicable to it
• CSS: false would mean the beautifier supports CSS, but none of the options are applicable to it
• CSS: [option1, option2, option3, etc...] would specify which options the beautifier supports for a language

Whatever the design ends up being, need to revisit getOptionsSupportedByBeautifierForLanguage and possibly other helper methods.

See:

• https://medium.freecodecamp.org/how-to-get-up-to-3500-github-stars-in-one-week-339102b62a8f
• https://gist.github.com/PurpleBooth/109311bb0361f32d87a2
• https://github.com/matiassingers/awesome-readme

Following up on @Glavin001's suggestion in avh4/elm-format#459 (comment),

what would be needed in order to add elm-format support to unibeautify?

https://github.com/Unibeautify/unibeautify/blob/master/src/DependencyManager/ExecutableDependency.ts#L18 only outputs the version from stdout. If for whatever reason a dependency prints to stderr for the version, which for the record should never ever be happening, it fails.

I installed Unibeautify 0.4.0 on VSCode 1.23.1 x64 Windows 10 from the VSCode marketplace and it was not working properly for me. Also, now the native VSCode html formatter is broken as well.

Afterwards, I tried to uninstall it, and it was stuck in Uninstalling state forever.

EDIT: uninstall works from the command-line (code --uninstall-extension Glavin001.unibeautify-vscode), just not the VSCode UI

• Move generic methods into utility class
• Break up methods in the Unibeautify class
• Reduce similar code, such as that within the findLanguages method
• Make getOptionsForBeautifier method less complex (edit: part of this may have to wait, as we've talked about returning an object that contains objects and errors, since errors are otherwise lost right now)

Removing task Return errors properly when going through methods

We need to use the file extension for the tmp file's postfix when creating a temp file. For executable beautifiers that support multiple languages, there is no way to know the extension to use there with the current BeautifierBeautifyData interface.

See Unibeautify/playground#21 and https://travis-ci.org/Unibeautify/playground/jobs/366600201#L2994

WARNING in ./node_modules/unibeautify/dist/src/DependencyManager/NodeDependency.js
39:32-39 Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
 @ ./node_modules/unibeautify/dist/src/DependencyManager/NodeDependency.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/index.js
 @ ./node_modules/unibeautify/dist/src/index.js
 @ ./src/Container.tsx
 @ ./src/App.tsx
 @ ./src/index.tsx
 @ multi ./src/index.tsx
ERROR in ./node_modules/unibeautify/dist/src/DependencyManager/ExecutableDependency.js
Module not found: Error: Can't resolve 'child_process' in '/home/travis/build/Unibeautify/playground/node_modules/unibeautify/dist/src/DependencyManager'
 @ ./node_modules/unibeautify/dist/src/DependencyManager/ExecutableDependency.js 3:24-48
 @ ./node_modules/unibeautify/dist/src/DependencyManager/index.js
 @ ./node_modules/unibeautify/dist/src/index.js
 @ ./src/Container.tsx
 @ ./src/App.tsx
 @ ./src/index.tsx
 @ multi ./src/index.tsx
ERROR in ./node_modules/requireg/lib/requireg.js
Module not found: Error: Can't resolve 'fs' in '/home/travis/build/Unibeautify/playground/node_modules/requireg/lib'
 @ ./node_modules/requireg/lib/requireg.js 1:11-24
 @ ./node_modules/unibeautify/dist/src/DependencyManager/NodeDependency.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/index.js
 @ ./node_modules/unibeautify/dist/src/index.js
 @ ./src/Container.tsx
 @ ./src/App.tsx
 @ ./src/index.tsx
 @ multi ./src/index.tsx
ERROR in ./node_modules/requireg/lib/resolvers.js
Module not found: Error: Can't resolve 'fs' in '/home/travis/build/Unibeautify/playground/node_modules/requireg/lib'
 @ ./node_modules/requireg/lib/resolvers.js 1:11-24
 @ ./node_modules/requireg/lib/requireg.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/NodeDependency.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/index.js
 @ ./node_modules/unibeautify/dist/src/index.js
 @ ./src/Container.tsx
 @ ./src/App.tsx
 @ ./src/index.tsx
 @ multi ./src/index.tsx
ERROR in ./node_modules/requireg/node_modules/resolve/lib/async.js
Module not found: Error: Can't resolve 'fs' in '/home/travis/build/Unibeautify/playground/node_modules/requireg/node_modules/resolve/lib'
 @ ./node_modules/requireg/node_modules/resolve/lib/async.js 2:9-22
 @ ./node_modules/requireg/node_modules/resolve/index.js
 @ ./node_modules/requireg/lib/resolvers.js
 @ ./node_modules/requireg/lib/requireg.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/NodeDependency.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/index.js
 @ ./node_modules/unibeautify/dist/src/index.js
 @ ./src/Container.tsx
 @ ./src/App.tsx
 @ ./src/index.tsx
 @ multi ./src/index.tsx
ERROR in ./node_modules/requireg/node_modules/resolve/lib/sync.js
Module not found: Error: Can't resolve 'fs' in '/home/travis/build/Unibeautify/playground/node_modules/requireg/node_modules/resolve/lib'
 @ ./node_modules/requireg/node_modules/resolve/lib/sync.js 2:9-22
 @ ./node_modules/requireg/node_modules/resolve/index.js
 @ ./node_modules/requireg/lib/resolvers.js
 @ ./node_modules/requireg/lib/requireg.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/NodeDependency.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/index.js
 @ ./node_modules/unibeautify/dist/src/index.js
 @ ./src/Container.tsx
 @ ./src/App.tsx
 @ ./src/index.tsx
 @ multi ./src/index.tsx
ERROR in ./node_modules/rc/index.js
Module parse failed: Unexpected character '#' (1:0)
You may need an appropriate loader to handle this file type.
| #! /usr/bin/env node
| var cc   = require('./lib/utils')
| var join = require('path').join
 @ ./node_modules/requireg/lib/resolvers.js 4:9-22
 @ ./node_modules/requireg/lib/requireg.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/NodeDependency.js
 @ ./node_modules/unibeautify/dist/src/DependencyManager/index.js
 @ ./node_modules/unibeautify/dist/src/index.js
 @ ./src/Container.tsx
 @ ./src/App.tsx
 @ ./src/index.tsx
 @ multi ./src/index.tsx

Important: Read Unibeautify/vscode#21 (comment) for why Unibeautify does not only use the beautifier's respective configuration files (i.e. prettierrc for Prettier, eslintrc for ESLint, etc).

Add option like prefer_beautifier_config.

Example

When Unibeautify is iterating over the selected beautifiers and reaches beautifier Prettier and the beautifier's config is set to preferBeautifierConfig=true then Unibeautify should pass Prettier's config directly: https://prettier.io/docs/en/api.html#prettierresolveconfigfilepath-options

Do you think prefer_beautifier_config should be enabled or disabled by default? Read explanation at #48 (comment)

A place for us to discuss ideas 😃 .

/cc @prettydiff @bitwiseman

See Playground

Before:

function test() {
    // unibeautify:disable
console.log("Test1");
    // unibeautify:disable
console.log("Test2");
}

function helloWorld() {
	// unibeautify:disable
console.log('Hello World');
	// unibeautify:disable
console.log('Hello World');
}

After:

function test() {
    // unibeautify:disable
console.log("Test2");
}

function helloWorld() {
	// unibeautify:disable
console.log('Hello World');
	// unibeautify:disable
console.log('Hello World');
}

Our current CodeClimate configuration consists of the below. We should decide how best to have it configured for all of the repos (stuff like number of lines a file, number of lines in a method/function, etc). Specifics can be found here: https://docs.codeclimate.com/docs/maintainability

version: "2"
checks:
  argument-count:
    enabled: true
    config:
      threshold: 4
  complex-logic:
    enabled: true
    config:
      threshold: 4
  file-lines:
    enabled: true
    config:
      threshold: 250
  method-complexity:
    enabled: true
    config:
      threshold: 5
  method-count:
    enabled: true
    config:
      threshold: 20
  method-lines:
    enabled: true
    config:
      threshold: 25
  nested-control-flow:
    enabled: true
    config:
      threshold: 4
  return-statements:
    enabled: true
    config:
      threshold: 4
  similar-code:
    enabled: true
    config:
      threshold: #language-specific defaults. overrides affect all languages.
  identical-code:
    enabled: true
    config:
      threshold: #language-specific defaults. overrides affect all languages.
exclude_patterns:
- "dist/"
- "**/node_modules/"
- "/test/"
- "**/*.d.ts"

I'm unable to compile the typescript files due to an error

Type 'DocumentLoadResult' is not assignable to type 'GitHubLanguages'. Type 'undefined' is not assignable to type 'GitHubLanguages'.

on this line: https://github.com/Unibeautify/unibeautify/blob/master/scripts/update-languages.ts#L30

• https://github.com/github/linguist/blob/master/lib/linguist/languages.yml
• https://github.com/prettier/prettier/blob/4c9d4061daed4b8d3e84cfdd8f224a15f0881684/src/language-graphql/index.js#L5-L19

Just want to raise awareness about https://github.com/google/code-prettify
Thank you

Continuation of #4 and related issues.

Languages like PHP often embeds HTML inside. HTML also embeds JavaScript and CSS inside.
Unibeautify should have first class support for breaking a file into languages and embedded languages, and applying the corresponding language beautifiers in series.

See:

• https://github.com/prettier/prettier/blob/master/tests_config/run_spec.js
• https://github.com/prettier/prettier/blob/e5d6a4704f2427cdf3baa0a1c941dd797c513993/jest.config.js#L6
• https://github.com/prettier/prettier/tree/master/tests/typescript_tsx

I think it would be better if we stayed consistent with the naming and function of options in relation to whether they should do something or should not do something. Take these options:

• indent_comments (comments should be indented)
• indent_inner_html (<head> and <body> section should be indented)
• indent_scripts (scripts should be indented)
• unindent_chained_methods (chained methods should not be indented)
• keep_array_indentation (array indents should be ignored)

The odd ball is unindent_chained_methods. This should probably be changed to indent_chained_methods with the default flipped from false to true. That would preserve existing behavior an be consistent with the other options.

Thoughts?

Atom-beautify is not a beautifier or framework. It is an adapter that lets users beautify JS or other languages, but depends on other tools to do the beautifying. Those tools have no awareness of atom-beautify and can have wildly different internal design and implmentation. Determining the cause of issues is difficult because in might be from any of several tools or from interaction with those tools.

A beautification framework would provide facilities that other components would plug into. For example, the framework might provide a facilities to configure formatting rules and read input, establish APIs or base classes for parsed token trees, execute all requested formatting rules on those tokens, and then have one unified implementation of an output writer. This would not support tools outside this framework, but would make it significantly easier to analyze and fix issue.

Unibeautify can do either of these or both, but I'd make sure we've talked about it early rather than later.

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

See the original issue for more details.

• Options values will determine the default beautifiers chosen
  • This allows configuration files, such as .jsbeautifyrc to contain a field default_beautifiers and therefore be automatically configurable while switching different projects.
  • See Glavin001/atom-beautify#1041
• default_beautifiers will accept an array (of course) and process the text sequentially.

Ideas below. This would be used across all unibeautify projects.

https://github.com/winstonjs/winston (mind as well use the 3.0.0 RC)