Autocomplete and Substitution Rules don't play well together

Issue #597 resolved
Andrew Visser created an issue

We have a pretty complex setup here, with multiple, dependent, managed packages. The namespaces for those packages is versioned (e.g. CoreV1, CoreV2).

All of our Apex code in packages that depend on Core refer to just "Core" (e.g.

Core__Custom__c.Core__Field__c

During our deploy we substitute Core => CoreVx for whatever the appropriate version is. Substitution rules handle this brilliantly.

However, completion does not reflect the substitution rules. So when I'm typing obj.Core__Field <hit tab> I get obj.CoreV2__Field__c. I want obj.Core__Field__c to be the replacement text.

Please let me know if I can provide additional details.

Comments (5)

  1. Scott Wells repo owner

    I'll provide a more lengthy response in a bit (stuck in an all-day meeting!), but IC actually has first-class features for this that are independent of substitution rules. You basically set up your "official namespaces" that would be used in your official managed package(s), and IC automatically translates back-and-forth between that and the dev org namespace(s) for you. You always work in the official namespaces.

    More details to come when I get more time...

  2. Andrew Visser Account Deactivated reporter

    Thanks for the quick reply.

    I looked at "Develop multiple managed packages in a single organization" @ http://www.illuminatedcloud.com/home/connections.

    I can't see that advanced tab in my connection options. Does that only show up when I include multiple packages on a connection?

    On our team, both the base and extension packages are managed. As a result, we spin up separate orgs to develop each - none of my connections get more than one module. Does that put this feature out of my reach?

  3. Scott Wells repo owner

    I've changed things quite a bit since documenting/recording that. I really need to update that info.

    I can help you set things up so that you can develop both managed packages in a single dev org. You'll still need multiple orgs for real packaging, but for ongoing dev I can help simplify your workflow dramatically. Let me get out of this marathon meeting and I'll provide more info. A quick screenshare might even work well to get yours set up, then you can help others on your team do the same.

  4. Scott Wells repo owner

    Okay, so here's a short version to get you started, then we can talk about what's not working with this implemented. Instead of using substitution rules, instead make sure that the configured connection's Organization Namespace is properly populated by clicking the Test button in the config screen for that connection. Given your example, you should see CoreV2 where you see base_dev in the following image:

    OrganizationNamespace.png

    Then open the project-level settings where you associate modules with connections. You'll want to use a module for your base package and a module for each extension package, and you'll want to use Development Packages in the org to segregate those as well (the Development Package for the base package should be selected as Managed in the org). Then you'll want to specify the Official Namespace values for each package, in your example, Core and in mine base, e.g.:

    OfficialNamespaces.png

    You'll also notice that the module for the extension package is configured for the appropriate Official Namespace (the one you want to use for the real extension package namespace), in my example ext.

    You'll need to set up module dependencies from your extension package modules to your base package module as follows:

    ModuleDependency.png

    With that config in place, regenerate your OST and you'll notice that only the official namespace(s) are represented in the OST and not the development organization namespace:

    OfficialNamespacesInOst.png

    and that completions, reference navigation, etc., are based on official namespaces and not the development organization namespace:

    BasePackageCompletion.png

    Again, you don't need substitution rules for this. It's a first-class feature I built into the IDE because I also work with a base package and multiple extension packages on a daily basis where each developer has his or her own dev org with a unique variation on the base package namespace.

    Give this a shot and let me know if you have any trouble setting it up!

  5. Scott Wells repo owner

    I'm going to resolve this for now. Please let me know if the provided instructions don't help you to get this going to your satisfaction.

  6. Log in to comment