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.

PS. I am making this post in the Ecosystem Design Announcements category as requested at the end of the README. Seems strange though.



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.


Thanks, Ian! That is all the information I was looking for :+1:

@ibuchanan is correct here. To provide some additional context this parser is used internally in Jira for our client side parsing of JQL, and was released to the public as part of a series of packages to improve the ecosystem developer experience with JQL (see Advanced search just got easier for Atlassian app developers - Atlassian Developer Blog).

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.

1 Like

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.


Asking for a friend, :wink: does your team have any plans to move this library out of atlassianlabs into a fully supported open-source project?

Thank you!

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

Hey @ibuchanan yes that is our long term goal however we have no roadmap yet for this change.

@kazimir_io please follow the workaround documented here until we can land additional fixes to improve Webpack 5 compatibility.

1 Like

There’s also unsolved discrepancy with dependencies on prosemirror exact versions which causes issues. Described in this thread JQLEditorConnect render error - #3 by HelderAlves

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:

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.