There was really no reason for this to be a nested function, since
we weren't closing on any variables. Flatter is better. Also, it
is plausible that folks will want more control over creating
individual jQuery elements (but still want this helper).
This is a first pass at fixing node docs. This commit eliminates
some text that is either obsolete or just overly confusing, and
it fixes some of the code samples to reflect how the API has
evolved in the last couple years. We also prominently tell
you how to run the tests.
We now allow you to run --coverage on individual files. This helps
when you want to make sure a file is being covered directly and not
just getting incidental coverage from higher level tests.
Before this commit, we were conflating wanting coverage reports with
wanting coverage checks. For individual files, we now solve that by
simply eliminating the coverage checks. This required some minor
refactoring to extract some functions.
I don't think anybody ever really used this feature, which I
developed but don't even use myself. It kind of runs counter
to the minimalist approach of the rest of node tests.
I would eventually like to re-think the template tests altogether.
They're slow, and we could solve that somewhat by replacing
jsdon/jquery with an HTML parser library to verify structural
things.
It's also possible that we can just rely on our template linters
to catch the biggest class of errors (malformed tags) and let
code review do the rest.
And it's also possible that we should make a second attempt to
ramp up tooling on making it easy to verify templates, but it
doesn't have to be part of the node tests. If we did that, we
would also potentially use tooling for Python-side templates.
This node test module is intended as a way for somebody to
quickly immerse themselves in our node testing methodologies,
plus it has the nice side effect of introducing several modules
(albeit very briefly).
A few things here:
* Use _.each to follow our convention.
* Just use new locals to avoid overwriting template and
avoid strange Object.assign hack.
* Just use simple string concatenation.
* Use better var names: full_name, shortcut
* Use chaining syntax.
This logging was apparently broken when sorting imports; it's a fairly
unique thing in our codebase that this would be a problem. Prevent
future regressions by adding this exception explicitly to the isort
configuration.
Our recent addition of Content-Security-Policy to the file uploads
backend broke in-browser previews of PDFs.
The content-types change in the last commit fixed loading PDFs for
most users; but the result was ugly, because e.g. Chrome would put the
PDF previewer into a frame (so there were 2 left scrollbars).
There were two changes needed to fix this:
* Loading the style to use the plugin. We corrected this by adding
`style-src 'self' 'unsafe-inline';`
* Loading the plugin. Our CSP blocked loading the PDf viewer plugin.
To correct this, we add object-src 'self', and then limit the
plugin-type to just the one for application/pdf.
We verified this new CSP using https://csp-evaluator.withgoogle.com/
in addition to manual testing.
Previously, user-uploaded PDF files were not properly rendered by
browsers with the local uploads backend, because we weren't setting
the correct content-type.
This rule checks for use of const wherever needed, currently does
nothing since we don't use `let`, instead we use `var`. This rule
can be used to use refactor a file to use const easily by replaceing
var with let using a editor and then by running
`./node_modules/.bin/eslint frontend_tests --fix --cache`. And then revert
those `let`'s back to `var`.
These aren't perfect -- in particular "core chat experience" can
probably be broken up -- but I think they help in making a quick skim
work for getting some sense of what the changes are.
This change just reorders and adds headings, with virtually no wording
changes.
Caches in Circle are immutable -- even if a path in a cache changes in builds
after the cache was created, the cache is not updated if it already exists. This
was making the zulip-venv-cache and zulip-npm-cache directories useless on
Circle.
This commit changes the cache keys to depend on the checksums of the dependency
manifests (requirements/{dev,thumbor}.txt, package.json and yarn.lock). This
would ensure that the caches are updated when the environments change. It may
result in the occasional build being "uncached" -- when a dependency manifest
changes -- but builds without such changes will be much faster, and such builds
are a majority.
Previously, a code block with a small width would be displayed
inline with the previous paragraph's text.
To fix this, now every p inside an li element except the first is
a block instead of an inline-block. However, this only applies to
li elements for integration instructions.
This makes sense intuitively because if there are multiple p's
in a list element, not all of those should be inline-blocks. The
first one should be because it needs to be inline with the list
number. The rest should be treated (and displayed) as separate
paragraphs.
Another thing to keep in mind is that the way Markdown code
blocks get converted to HTML is such that every code block
becomes <p><code></code></p> when converted to HTML.
We let Markdown increment the list step numbers, which is more
reliable than keeping track of numbered-steps manually.
Also, instead of linking to the CircleCI docs, we now have full
instructions for how to setup a webhook by modifying the circle.yml
file.
Ancient GitLab from several years ago doesn't include the
HTTP_X_GITLAB_EVENT header (and seems to have a different format), so
we should ignore its requests.
Might be good to document the version threshhold, but it's very hard
to tell from Googling what it is.
Greg Price
Steve Howell
Tim Abbott
Aditya Bansal
Cynthia Lin
Vishnu Ks
Priyank
Eeshan Garg
Puneeth Chaganti