I am trying out VSCode on an existing project that uses npm and has a package.json file with a corresponding "name:" key that reads "SpecPro-File-Management-UI". VSCode is objecting to this line with "String does not match the pattern ...", apparently because of the upper-case characters in the name.
This problem is described in a VSCode issue which is closed. Which leaves me with advice to setup a custom schema for my package.json file. This is pretty unfriendly, and a barrier to adopting VSCode. I don't want to spend my time on custom schemas. I don't want to rename my project. I just want to edit my code and take advantage of the many VSCode goodies without distracting messages that are wrong.
Considering that using uppercase characters for npm packages is a VERY common practice, it seems most reasonable that VSCode should adopt either a more friendly schema or an easy way to override the standard schema. As far as I can tell, I have to make my own personal schema to resolve this problem. That's a lot of work and future maintenance for such a simple issue.
Is there an easy way to banish this erroneous error message?
This behavior is by design to enforce NPM conventions for the package.json file (to paraphrase, "lower-case only"). I agree it is a nuisance, especially since the project name is often pre-filled, e.g. by "create-react-app". As you point out, it is possible to create a custom schema to ignore this, but it's really not recommended. There isn't any alternative at this time. Myself, I just change the value to lower-case.
Use name field value in lowercase separated by hyphen (-).
In tsconfig.json add this line or set its value to false.
This worked for me.
"forceConsistentCasingInFileNames": false, // Fix for name regex pattern
Related
When two PHP files are on the same namespace, adding a "use" to them for the other one is not necessary, but possible. However, PhpStorm inspection marks the unnecessary uses on PHP files as errors, warns about using them, and does not autocreate them when typing the class name on the file.
The thing is, I like having them on the file even that they are not necessary. That makes me easier to check the file dependencies, and to search-replace the namespaces when I move classes around. I know about the refactoring features of PhpStorm, but they are not always available for me and my co-workers.
So, is there a way of telling PhpStorm to behave with unnecessary uses as it does with regular ones? Not marking them as errors, autocompleting, etc.
I've started researching LDAP and started following a tutorial to at least start familiarizing with it. While doing that, I noticed that there is an odd (for me) notation in the /usr/share/slapd/slapd.conf file on my computer, namely #SUFFIX# and other things surrounding by the at sign. I think that this is supposed to be interpreted as some kind of a variable or substitution point, but any search on Google turned out nothing, as they ignore special characters.
How should I interpret this and where can I change it?
Sounds like you're talking about the slapd.conf template from the Debian package. #SUFFIX# and the other tokens in that file are replaced at configure time by the maintainer scripts.
(The package also contains a similar template for dynamic configuration; slapd.conf is no longer used.)
I want to edit find_under_expand (ctrl+d) to consider hyphenated words, as single words. So when I try to replace all instance of var a, it shouldn't match substrings of "a" in words like a-b, which it currently does.
I'm assuming find_under_expand wraps your current selection in regex boundaries like this: \ba\b
I need it to wrap in something like this: \b(?<!-)a(?!-)\b
Is the find_under_expand command's source available to edit? Or do I have to rewrite the whole thing? I'm not sure where to begin.
Sublime's commands are implemented in one of several ways: as macros, as plugins, and internally as part of the compiled program (probably as C++). The default macros and plugins can be found in the Packages/Default directory in ST2 (where Packages is the directory opened when selecting Preferences -> Browse Packages...), or zipped in the Installed Packages/Default.sublime-package file in ST3, extractable using #skuroda's excellent PackageResourceViewer plugin, available via Package Control. Macros have .sublime-macro extensions, while plugins are written in Python and have .py extensions.
I searched all through the Defaults package in ST3 (things are generally the same as in ST2), and was unable to find a macro or .py file that included the find_under_expand command, or FindUnderExpand, which is the convention when naming command classes in plugins. Therefore, I strongly suspect that this command is internal to Sublime, probably written in C++ and linked into the executable or in a .dll|.dylib|.so library.
So, it doesn't look like there's an existing file that you could easily modify to adjust for your negative lookahead/lookbehind patterns (I assume that's what those are, my regex is a bit rusty...). Instead, you'll have to implement your own plugin from scratch that reads the "word_separators" value in your settings file, which the current implementation of find_under_expand doesn't seem to be doing, judging from your previous question and my own testing. Theoretically, this shouldn't be too terribly difficult - you can just open up a quick panel where the user enters the pattern/regex to be searched for, and you can just iterate through the current view looking for matches and highlighting/selecting them.
Good luck!
Why is changing lines in configuration file considered an anti-pattern in Chef or Puppet?
It's something like bad habit, as I understood. I assume that this file-editing is done in some idempotent way and with advanced tools (augeas for example).
Why is deploying the whole files, with ERB templates, considered a preferred method?
You can find a lot of examples where dev-ops are suggesting usage of templates instead of file-editing. For example here, here, here, etc.
Actually there is a large part of the DevOps community that sees accepting system/package defaults for config files and only modifying what you need through augeas as the preferred method, Github devops would be one of them(if you happened to catch them at Puppet Conf 2012).
I think having a default pattern of always using templates creates too high of a maintenance load and almost always requires you lock in specific versions for everything across your stack or you risk having an incompatible template against a newer version of that resource.
There's use cases for both options but in general I favor the "own as little as possible" practice vs the "own everything even if you don't have to" practice.
In terms of setting the your system to a known state, deploying whole files is better than editing, because you are sure the file is exactly as intended when you are done.
If you are tinkering around finding potential solutions to a problem and hand edit some configuration file, you don't have to worry about the hand edit you made staying around as an uncontrolled part of your environment. The next time you run chef-client, you know that the state will be exactly as specified in the Chef recipe, and won't include your edit.
Also, it is just in general harder and more complicated to robustly edit a file than it is to just generate one. You might write something that is idempotent in the basic case, but if the file contains a syntax error or something invalid, than your editing no longer works.
As always though, sometimes you don't have a choice, and editing is the only way to go.
I have a binary file to which I'm trying to write however I dont have the file format specification nor have found it using google, I've been looking at the file using a hex editor but so far has only give me a headache, is there a better way to decipher the format of the file so that I can append data to it?
File carving tools such as scalpel won't really help here. They're made for extracting files with known header and/or footer signatures from a memory dump or some larger, composite file.
For your scenario, I would recommend a hex editor with templating capability, like the 010 Editor. This will allow you to name and annotate "fields" in the binary as you learn more about what each part of the file does. Unfortunately, the process of finding out what each field does is mostly manual. As a methodology, just start playing with it. Change some values in your current binary and see what happens. Expect to spend significant time on it, but also enjoy the process!
you may want to search it with a open source forensic application like foremost or scalpel. They will do most of the grunt work for you, you just likely wont learn anything.