Support for Change Set Based Development

[squibobblepants]

Summary

It would be brilliant if the Apex, Lightning, and Visualforce Code editor extensions could apply to any Apex classes / Lightning Components / Visualforce pages, regardless of whether they are contained inside an SFDX project.

At the moment, it is possible to sort-of monkeypatch the behavior in by creating a dummy sfdx-project.json file at the root of any other Salesforce project tree.

As the extensions grow and evolve, I fear that this affordance will be lost. This would be a huge loss to a lot of developers who are stuck in a world where porting older, larger, more ungainly projects into DX is impossible/impractical.

Steps To Reproduce:

1. Get a local copy of a Salesforce Org in the non-DX way (e.g. with MavensMate)
2. Add a sample sfdx-project.json to the root of the project (I just copied in the one from dreamhouse and it seemed to work)
3. Open it in VSCode
4. Enjoy wonderful realtime tab completion and syntax highlighting without having to wait for a round trip to the Org to complete

Additional information

Perhaps associating the language sets with certain file extensions would be really useful, so that we could choose / override / configure at a per workspace level within VSCode, rather than having to list folders in the json file?

VS Code Version: 1.16.1

SFDX CLI Version: sfdx-cli/5.7.6-d42cf65 (windows-amd64) go1.7.5 sfdxstable

OS and version: Windows 10 Pro

[guw]

The are technical reasons why the Apex LS relies on a DX project. Primarily it's related to how the language service decides what's available in content assist. Also, there might be additional features in the future which rely entirely on a DX project, i.e. it was a decision made upfront that it will only support DX projects. FWIW, there is still the Force.com IDE and a lot more fantastic tools from partners for people not using DX.

Introducing non DX projects into the Apex LS is a significant undertaking and not every feature might be possible. It is possible, though.

[squibobblepants]

It would be super handy for consultancies where you are often working inside orgs that have not been maintained by a single developer/team and have various code strewn all over the place!

I understand that the priority has to be to DX, but even limited (or not deliberately nixed!) support would provide a lot of help. Just to reiterate, it does actually partially work with non-dx projects, as long as you add an sfdx-project.json to the root of the folder - it at least gets you the APEX class completion and syntax highlighting :)

The Force.com IDE is very much a backup option for me because VSCode is my primary editor for all things and I'd like to keep it that way! Of course, I don't just want to be a moaner, so I will be looking to contribute as and when I get the chance.

[JimBTek]

I am a consultant as well. Currently I rely on IDEA and Illuminated Cloud. I would love to use VS Code for Salesforce with a Salesforce supported/provided solution, not 3rd party. Dev is so fragmented right now, and saying that going forward you have to buy DX to have the new code editor for Salesforce just fragments even more.

Please consider one plugin that gives you extra features if you are using DX, but still provides all the core tools for any Org. That way consultants can switch between projects and Orgs with ease inside one system.

[renatoliveira]

Having an extension to work just with DX makes sense only if Salesforce released DX to everyone (including Developer Edition users, with some limitations like the number of scratch orgs, instead of 30-day trial). This isn't the case, however.

Also, the Force.com IDE is not what I would call developer friendly (I had a terrible experience with it on both Windows and macOS).

[Shababsoft]

@vazexqi - Any update on this feature? I believe most customers still use sandboxes for development. Eclipse IDE and Force.com Plugin are not good for fast development, specially not good option for lightning components.

[vazexqi]

@Shababsoft - It is on our roadmap this year. Customers should be able to use one development environment, that is VS Code with our extensions, for any Salesforce project.

See this tweet from Wade https://twitter.com/WadeWegner/status/965932714107985922 More details will be available soon.

[vazexqi]

More information now posted at the Salesforce Developer Blog – https://developer.salesforce.com/blogs/2018/02/salesforce-extensions-vs-code.html

[JimBTek]

@vazexqi this is all great, thanks! I did notice though that the Blog post and the Extension page both only focus on DX. Also the blog post throws a "login to staging.developer.salesforce.com" pop up. Any way to share what quarter we might see Extension support for non-DX clients?

[dylanribb]

Customers should be able to use one development environment, that is VS Code with our extensions, for any Salesforce project.

Just to clarify, does this mean that we'll eventually be able to use the VS Code tools/extensions to upload to/download from a Sandbox directly? I love VS Code and the tools the team has created so far, but the development cycle with scratch orgs is still (imho) fairly clunky compared to just developing directly in a Sandbox and then deploying changes and unfortunately not everyone is able to easily export their existing code, objects, etc, to an unmanaged package and set them up in a new scratch org...

[ntotten]

@dylanribb Sorry for the delayed response. Yes, you will be able to use VS Code directly with sandboxes later this year. 😃

[vazexqi]

See https://github.com/forcedotcom/salesforcedx-vscode/wiki/Develop-Against-Any-Org-in-Visual-Studio-Code

This is something that we will demo in-depth during Dreamforce but you can try it out now.

[JimBTek]

excellent! now we just need a way to generate a complete Package.xml file :) I'm playing with force cli, Solenopsis and SFDX and nothing gives you a complete export of metadata for Sales Cloud clients (non managed paclage orgs)

[msrivastav13]

@JimBTek I think one tool i find it handy to generate package xml is https://packagebuilder.herokuapp.com/ . Try that and you can generate the package xml.

[JimBTek]

@msrivastav13 yeah, that doesn't quite help with CI though if I want to auto-create a package of:

• all exportable metadata for backup purposes
• all exportable metadata minus manage packages
• all deployable metadata for syncing sandboxes or scratch orgs exactly as possible

Or i just export all metadata and then use some scripting to strip out folders and files that are not deployable.

Currently I have a package.xml that I built with Gearset, using it with the new force:source:retrieve in VSCode perfectly, but it fails to force:source:deploy with a ton of errors (support: 504355533-24678)

seems like all my classes and triggers error out: 1093284688-6134

profiles are plagued by this: force-app/main/default/profiles/Standard.profile-meta.xml In field: application - no CustomApplication named standard__LightningInstrumentation found (43:30)

EDIT: Looks like classes and triggers will deploy on their own (if you select just their folder) but not with the entire package, then it gets errors:

sfdx force:source:deploy --sourcepath /force-app/main/default/triggers

[msrivastav13]

I think you can also use https://www.npmjs.com/package/package-xml npm to generate package.xml from the source code if you have in the repo .The other thing that is missing is this should give us ability to pull source from the unmanaged package .

[JimBTek]

@msrivastav13 yeah, there are a lot of good options for the sfdx team to look at. My point here is that sfdx should be as intelligent about generating a deployable package.xml as these third party tools for everyone to adopt it. sfdx is def. the future and the tie-in with VS code is great.

But having to install node on CI/CD in something like GitLab is a pain, and takes more time, and then it requires more tooling. Then I have to worry about all of my team members having multiple tools and environments setup properly on their local machines.

I prefer ANT and Solenopsis since they run on just a java stack, sfdx does as well.

[ChuckJonas]

@JimBTek Isn't getting a node container as simple as just setting image: node:6 in your .gitlab-ci.yml?

[JimBTek]

then you lose openJDK

and again then you have more stuff to keep in sync on dev computers when you want to use almost the same process for both manual scripting and CI scripting. So yes you can do all this, but for sfdx cli to be the "full package" for both ISV and consulting partners, you would expect it to be a lot easier to "pull all the metadata from Prod to my filesystem, check it in to git, and then push it all to a sandbox." and these other tools do provide semi-workable options

and in particular with gitlab you can't install node after selecting an openjdk image and be able to access it's commands, so you have to have a custom docker image with both declared in it.

On Mon, Aug 27, 2018 at 11:14 AM Charlie Jonas notifications@github.com wrote:

@JimBTek https://github.com/JimBTek Isn't getting a node container as simple as just setting image: node:6 in your .gitlab-ci.yml?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/forcedotcom/salesforcedx-vscode/issues/123#issuecomment-416260749, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHzG-mbwAUSPBMgdNqAcUtEZ5ARTJCcks5uVAzDgaJpZM4PclNt .

[wrone]

will it be able to push (not deploy) code to a regular org, without overwriting the whole class? or will it notify if there is a conflict? it will be great to have a such feature