Closed AndrewTziAnChan closed 4 years ago
Hrmm... looks like its trying to iterate over an empty command field. Let me get back to you.
Looks like there is a bug on windows. I'll look into it this evening.
Fixed in https://github.com/bcomnes/sublime-standard-format/releases/tag/v6.1.3
Package control should auto update within the hour. Apologies for the inconvenience and thanks for pointing this out.
Let me know if there are still issues and we can reopen.
There's now a different error. Unsure if related to previous error.
Traceback (most recent call last): File "C:\Program Files\Sublime Text 3\sublimeplugin.py", line 818, in run return self.run(edit) File "standard-format in C:\Users\Achan\AppData\Roaming\Sublime Text 3\Installed Packages\StandardFormat.sublime-package", line 272, in run File "standard-format in C:\Users\Achan\AppData\Roaming\Sublime Text 3\Installed Packages\StandardFormat.sublime-package", line 276, in do_format File "standard-format in C:\Users\Achan\AppData\Roaming\Sublime Text 3\Installed Packages\StandardFormat.sublime-package", line 197, in standard_format BrokenPipeError: [Errno 32] Broken pipe
Ah dang.
I'll try to re-create.
@AndrewTziAnChan can you post your user config for the plugin, and also explain how you are installing standard? (e.g. a global install or a project local dev-dependency?)
Ah, sorry for the red herring. While playing around with the various settings, I set my user configs to not use the global path so node couldn't be found.
I've set use_global_path back to true.
Now, the format is working. The only issue now is that whenever the standard format is run, the following is output to the top of the file:
The react/jsx-space-before-closing rule is deprecated. Please use the react/jsx-tag-spacing rule with the "beforeSelfClosing" option instead.
As an additional detail, standard is installed locally at the project level. Standard is not installed globally.
I'll twiddle with the settings more on windows to make sure there are no fail states.
As for the output inserting into the file, it sounds like maybe an old version of standard is installed. I've been meaning to put hard check on this in the plugin for a while.
The version installed in my project currently seems to be the latest version: 10.0.2
That specific output about the jsx-space-before-closing rule is still being written at the top of the file.
Is there any other setting I should change?
Can you post the output from the sublime console as you switch between JS files in a project that is triggering the issue?
There should be a message from standard-format with the global and local search path as well as the path to the command it's found
Enable these settings:
Apologies, was away on personal business.
Here's output from searching for standard locally:
found standard at C:\front-end-project\apps\my-project\node_modules.bin\standard.CMD
Here's standard version used:
standard version: ('10.0.2\n', b'')
Here's output when invoking fix:
b''
I dont have a windows machine anymore to test on. Sorry, but I have to close unless there is something else we can have action on.
Was attempting to run a simple format that had worked previously.
Turned on loud errors and found this error in the console:
Traceback (most recent call last): File "C:\Program Files\Sublime Text 3\sublimeplugin.py", line 818, in run return self.run(edit) File "standard-format in C:\Users\Achan\AppData\Roaming\Sublime Text 3\Installed Packages\StandardFormat.sublime-package", line 271, in run File "standard-format in C:\Users\Achan\AppData\Roaming\Sublime Text 3\Installed Packages\StandardFormat.sublime-package", line 275, in do_format File "standard-format in C:\Users\Achan\AppData\Roaming\Sublime Text 3\Installed Packages\StandardFormat.sublime-package", line 194, in standard_format File "./python3.3/subprocess.py", line 819, in init File "./python3.3/subprocess.py", line 1063, in _execute_child File "./python3.3/subprocess.py", line 632, in list2cmdline TypeError: argument of type 'NoneType' is not iterable
Tried running as Admin without success.
I can run standard --fix without issue.
Anyone seen this error before?