We have been looking for options to parse JQL outside of Jira and without calling the Jira API. As a result, we came across the following package:
Can anyone from @atlassian comment if this is an officially supported package that we can rely on? The README and documentation on that package are very limited and do not make statements on the project status or intended use. Any insights on this would be helpful.
I’m somewhat of a “language geek” so I was pretty excited a couple years ago when some of the Jira dev team created a formal grammar of JQL in ANTLR4. However, a grammar is a bit of a tricky case. While we do rely on the underlying g file (the grammar), the rest is code generation provided by ANTLR4. Also it isn’t the “authoritative” grammar, which lives with the Jira source code so there is a risk grammar changes would not propagate and rebuild the public Javascript library. Most of all, it is labeled “Atlassian Labs”, where the language is:
Atlassian Labs holds unsupported apps and personal projects by Atlassian developers. Although you may find unique and highly useful functionality in the Atlassian Labs apps, Atlassian takes no responsibility for your use of these apps. The apps are often developed in conjunction with Atlassian hack-a-thons and ShipIt days and are provided to you completely “as-is”, with all bugs and errors, and are not supported by Atlassian. Our bug-fix policy page - Security Bugfix Policy | Atlassian - describes how and when we resolve security bugs in our products, including apps listed here. Unless licensed otherwise by Atlassian, the Atlassian Labs apps are subject to Section 14 of the Cloud Terms of Service – Cloud Terms of Service | Atlassian – or Section 8 of the Software License Agreement – Software License Agreement | Atlassian, as applicable, and are “No-Charge Products” as defined therein.
While it is published under the @atlassianlabs scope it is a package we still rely on heavily within Jira and are continuing to support. You may also be interested in the @atlassianlabs/jql-ast - npm package which is a higher level abstraction of the parsed JQL and is a good fit for many use cases that need to traverse the query.
Hey @Kyle thanks for providing additional context - that’s really helpful. If this is something that teams within Atlassian are maintaining it’s a shame this is not advertised in the developer docs.
May I suggest putting the statement below from your blog into the package README? Or, alternatively link the blog in the README. This would have helped us understand the current state of the package.
These packages are currently in the initial development phase published to the @atlassianlabs scope. Once we’ve had an opportunity to review ecosystem feedback and adoption we will look to make final revisions to the API and promote a release to the @atlassian scope.
Currently, it looks like jql-editor family of libraries was released to public and then forgotten about by Atlassian.
It was released and never updated after that, UI components have the dependency on styled-components v3, which is not used in AtlasKit core libraries anymore and has several vulnerabilities in its dependency tree.
Are you able to share any kind of plans for these libraries, so we can decide whether we should use them, or they will never be updated anymore?
Hello @kazimir_io we have published a new version of our Forge and Connect JQL editor packages migrated to Emotion JS, aligned with Atlaskit.
We’re still actively maintaining these packages so if you have any additional feature requests or bug reports please continue raising topics in the community so we can triage them accordingly.
We’re now seeing errors like these when trying to build with webpack 5 and latest version of package:
ERROR in ./node_modules/@atlassianlabs/jql-editor/dist/esm/analytics/index.js 30:62-76
Should not import the named export 'version' (imported as 'packageVersion') from default-exporting module (only default export is available soon)
@ ./node_modules/@atlassianlabs/jql-editor/dist/esm/index.js 4:0-111 4:0-111 4:0-111 4:0-111 4:0-111
@ ./node_modules/@atlassianlabs/jql-editor-connect/dist/esm/async.js 3:0-59 7:15-29
@ ./node_modules/@atlassianlabs/jql-editor-connect/dist/esm/index.js 1:0-48 1:0-48
ERROR in ./node_modules/@atlassianlabs/jql-editor-autocomplete-rest/dist/esm/analytics/index.js 4:49-60
Should not import the named export 'name' (imported as 'packageName') from default-exporting module (only default export is available soon)
@ ./node_modules/@atlassianlabs/jql-editor-autocomplete-rest/dist/esm/state/index.js 3:0-53 54:18-32 55:25-64 66:18-31 67:25-64
@ ./node_modules/@atlassianlabs/jql-editor-autocomplete-rest/dist/esm/index.js 2:0-51 2:0-51
@ ./node_modules/@atlassianlabs/jql-editor-connect/dist/esm/ui/index.js 5:0-86 14:29-52
@ ./node_modules/@atlassianlabs/jql-editor-connect/dist/esm/async.js 4:0-42 6:42-60
@ ./node_modules/@atlassianlabs/jql-editor-connect/dist/esm/index.js 1:0-48 1:0-48
And it looks like that @atlassianlabs/jql-editor-autocomplete-rest still has a peer dependency on styled-components. Not sure if it’s actually has any code dependencies on it
UPD: It would also be nice to have the prop to disable input (eg, for when we’re submitting the form, loading, etc). And also a prop to disable multi-line input.
There’s also seems to be a compromised package in dependency tree now:
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ critical │ Malware in react-intl-next │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ react-intl-next │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ No patch available │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ @atlassianlabs/jql-editor │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ @atlassianlabs/jql-editor > react-intl-next │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://www.npmjs.com/advisories/1078722 │
└───────────────┴──────────────────────────────────────────────────────────────┘
It looks that it was already handled by NPM security team 8 months ago, and Yarn resolves it to react-intl package, so there’s likely no immediate threat: https://www.npmjs.com/package/react-intl-next
But it still throws an audit error and I think it should be fixed asap.
Can somebody look into this?
It seems ridiculous to have a such an overlook, and then to take forever to fix it without any concrete communication.
Especially considering that the fix is basically to replace one import in the source code to another (because the real react-intl is already used due to npm automated fix)
Hello @kazimir_io apologies for the delayed response.
I’ve created an internal ticket to track the Prosemirror dependency issue and will look to release a fix in the coming weeks. I’ve also created feature requests for disabling the input and multiline capabilities but this will still require triaging internally.
If you refer to the package.json of the jql-editor dependency you’ll see that there is a fixed resolution for react-intl already specified and I’ve come across no vulnerabilities when running npm audit myself.
We’re using yarn, and yarn audit raises the error even with the npm fix.
Also, it creates build issues since we end up with two copies of the same package under the different names, and sometimes only one is installing, or one overriding the other.
Because of this, we also have to create an alias from react-intl-next to react-intl to only have one react-intl instance in the build for end users.
Thanks for the information @kazimir_io to give some additional context this package is monorepo’d with many other components in the Atlassian design system, as such it’s not as trivial as changing the version in a single package. I’ll raise this problem with the design system team to see what there plan is for upgrading.
does your team have any plans to move this library out of