# Extend export functionality
**URL:** https://discourse.nodered.org/t/extend-export-functionality/12520
**Category:** Feature Requests
**Created:** [23 June 2019 19:25 UTC](https://discourse.nodered.org/t/extend-export-functionality/12520 "2019-06-23T19:25:33Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@moebius](https://discourse.nodered.org/u/moebius)
#### Post date: [23 June 2019 19:25 UTC](https://discourse.nodered.org/t/extend-export-functionality/12520/1 "2019-06-23T19:25:33Z")
The export functionality should be extended:
x include non standard nodes without external dependencies
x include non standard nodes with external dependencies (the dependency should be included in the export)
x include credentials
---
### Author:  [@knolleary](https://discourse.nodered.org/u/knolleary)
#### Post date: [23 June 2019 21:15 UTC](https://discourse.nodered.org/t/extend-export-functionality/12520/2 "2019-06-23T21:15:41Z")
Hi @moebius, can you explain a bit more about what the first two mean?
The export is the json flow definition. Do you mean it should include information about what npm modules provided the nodes in the exported flow?
> [@moebius](#):
>
> x include credentials
It has always been a specific design decision that the editor is not able to export credentials. This means we do not expose an api in the runtime that can be used to get the credentials remotely - thus avoiding a huge potential security risk.
That said, we have kicked around a few ideas on how that _might_ be relaxed. For example, only exposing that api if `adminAuth` has been enabled and only for authenticated users. Some more careful thought needed on how best to avoid a CVE further down the line.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [23 June 2019 21:42 UTC](https://discourse.nodered.org/t/extend-export-functionality/12520/3 "2019-06-23T21:42:24Z")
Maybe this should be more at the project level ? export project ? so it can include other artefacts other than just the flow.
---
### Author:  [@moebius](https://discourse.nodered.org/u/moebius)
#### Post date: [24 June 2019 11:07 UTC](https://discourse.nodered.org/t/extend-export-functionality/12520/4 "2019-06-24T11:07:59Z")
> [@knolleary](#):
>
> Do you mean it should include information about what npm modules provided the nodes in the exported flow?
Yes, the export now does not include any metainfo like exact node name, version nr, etc...
An ideal solution would allow one to include all nodes (and npm's) in the export optionally. This would also handle the potential problem, that a node or dependency changes and breaks the import.
@dceejay sure possible, but only if you allow multiple projects at once and that each tab could be a project.
---
### Author:  [@dceejay](https://discourse.nodered.org/u/dceejay)
#### Post date: [24 June 2019 11:29 UTC](https://discourse.nodered.org/t/extend-export-functionality/12520/5 "2019-06-24T11:29:31Z")
So if you have a flow that specifies a certain level of node and then import a new one which needs the same node but at a different level then you are into dependency merging etc... sounds much more like an overall project level capability - not multiple projects.
---
### Author:  [@moebius](https://discourse.nodered.org/u/moebius)
#### Post date: [24 June 2019 11:41 UTC](https://discourse.nodered.org/t/extend-export-functionality/12520/6 "2019-06-24T11:41:45Z")
I'm not sure if it should do merging - i guess it would sufficient to allow the user to decide if he wants to import and use the new node or not...
With multiple projects i mean that the editor should be able to handle more than one project at a time. So if you have 5 tabs, 4 can be one project and 1 another.