Is there a reason it has to be an sql query?  Using object syntax, opening the object whose list you want to check, and then checking it with something like myObj.myListProperty is a very good option if possible.

We now have continuous integration with Jenkins in Angular.

At a high level, the steps are:

1. add a line like ng test --code-coverage --browsers=ChromeHeadless to your build script

2. have Jenkins publish the code coverage HTML report with it's HTML Reports plugin

3. install karma-junit-reporter and have it output the test report to a location on the build machine where it can be globbed together with other junit test reports you want to publish

I'd be happy to talk about these steps more if anyone is doing the same thing.

That makes a lot of sense that you naturally avoid the abbreviations where the English word carries some significant meaning.  Also, it seems like you naturally avoid abbreviations where the abbreviation carries a sort of misleading semantic meaning. With $case vs $c, $c at first glance looks like some sort of character function, whereas $s and $H don't immediately appear to be something that they're not.

And I forgot about horizontal space; on lines that get long it's not trivial.  That said, things like $select, $HOROLOG, and $piece carry a lot of meaning through the full word, and I think there's value in that.

Side note: for some reason I always want to use $g instead of $get (I don't, but it feels natural).  I think that's because, as a single syllable word which is a very simple operation, after seeing the definition for $get once, $g seems to fit it just as well as the full "get".

This is a really good point I hadn't considered.

When I was working with legacy code bases, it was difficult.  However, perhaps I'm blaming the wrong culprit.  Looking back, the main issue is that all the variable names were two random letters (at least to me; by the end I could usually figure out what the two letters were supposed to mean).  I'd be down 15 lines and then have to go back up to a variable's initialization to remember what the heck "cb", "sh", or "ac" actually were, semantically.

That was probably also done to save characters, and, as you said, is far more damaging than set -> s or if -> i.

I also agree that the lack of appropriate spacing makes a huge difference, as appropriate spacing can help show the control flow of the code.  Thanks for commenting this; after reading it, I now think that of all the questionable (in today's world) space saving techniques used in the past, the single letter variable names might be the least offensive.

That said though, with respect to the seeing more at once, s -> set doesn't increase the vertical space at all, so in theory you can see the same number of lines.  Also, I think it's very useful for coding languages to be written in English.  Coding is complex enough as it is, so we might as well take advantage of the fact that we're already completely comfortable with English, and thus we don't need to waste any mental resources during the processing of English string -> semantic meaning.  By using English, we're hijacking our preconceived notions of words like "while" such that the jump to the more complex control flow operator is less severe.  I'd contend it would take far longer than a few hours to be able to really read "w" the way you can read "while".

It's just like learning a new (non-coding) language.  Once I know what the vocabulary words mean, I can competently translate a passage in that language.  But I can't read it yet, with a direct link from the text to the meaning.

From what I understand, the single character command names are an anachronism from a time when the actual space the code took up was more of a limiting factor.  Nowadays, that's not relevant at all, so the added readability of the full words is optimal.

I remember my first time looking at code bases using the single letters.  One of the worst offenders, 'i' instead of 'if' was very annoying; it makes reading the code more like translating and less like reading.

That article about pack and link was very helpful and informative.  Thanks for that.

It didn't address what I'm asking, though (unless it did, and I'm wrong).  I don't really need a css build tool, at least I don't think I do.  I literally just want to know how I can get a scss file from one project into the node_modules directory of another via npm.

When I used npm pack on project1 to create a tarball, then installed that tarball into project2, the css file from the project1 wasn't in tarball2's node_modules, and I'd like it to be (so I can import it somewhere in project2).

Interesting.  We already have all of our Cache code building, running unit tests, and running code coverage on Jenkins.  My current plan is to see how easy/difficult it is to fit Angular build/test/coverage into that architecture, so that we can have everything in once place.

If there are features we can't have with Jenkins, or if it turns out to be so difficult that it may be worth splitting up our continuous integration across multiple platforms, I'll definitely give this stuff a look.  Thanks for the advice.

Would something like that ever make sense if the queries were repeated a lot, across a lot of different applications?  (minus the deleting the query part)

I'd never actually thought of this before.  Have you ever implemented anything like that?  Actually now that I think about it more, it would make more sense to just post the query and have it run (and store if it's not there), rather than getting trying to GET the query first, getting back a 404 or something, and then POSTing it before getting it.

Like others have said, a /search endpoint is inherently non-RESTful.  Are you certain that /search endpoint shouldn't be something else? 

For example, if the search is searching people, then perhaps redesign it as a /person endpoint instead?  If that's the case, then a GET request to /person with URL parameters is definitely the most "RESTful" thing you can do; you're asking for ("GETing") information for a bunch of person resources.

If /search is really what you want, then it's not really following the RESTful architecture anyway, because you aren't asking for information about resources, you're really just asking the server to take an action for you and send you the result.  In this case, you might as well forget about RESTful conventions and just do whatever is most convenient and maintainable. 

I suspect that the user is filling out some sort of a form in the UI with these search parameters.  If that's the case, you might be able to simply POST the object that the form generates to the server, and then pull the parameters out of the request body in your server-side handler method.  In general, whether you're pulling the parameters out of %request.Data or out of  %request.Content, there isn't much code that needs to be written on the server.  So pick the option that makes the client code the most straightforward.