Failure with multiple compiled projects

[Marco Gadaleta]

Hi guys,

this is the problem: I have put, under bin folder, two different js files generated by plovr 5.1.

Under my bin this is the tree structure:

-bin

----- a.js (generated with a plovr config file)

----- b.js (generated with another one plovr config file)

The problem is that when I import these js files inside my "index.html" page, in consolle there is this error:

Uncaught Error: Namespace "goog.debug.Error" already declared.

and after an "Uncaught ReferenceError: ...." related to my second loaded file.

In other words the second loaded file in the html page generate a conflict with the first one.

There is a way to manage this kind of problem during compilation?

Thank you very mutch,

Marco

[Ilia Mirkin]

Use a wrapper.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "plovr" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to plovr+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Marco Gadaleta]

Can you give me an example please?

[Ilia Mirkin]

http://plovr.org/options.html#output-wrapper

On Mon, Apr 18, 2016 at 10:01 AM, Marco Gadaleta

[Marco Gadaleta]

I don't understand how this option can help me.

I've two different config files that produce two  different js files.

How output-wrapper can help me to fix conflict problem?

[Andre Tannus]

It will hide your variables in a closure scope and prevent them from colliding.

It's not magic, you'll still have problemas if the different packages *expose* colliding objects.

André Tannús | Epungo | +55 11 2389-4360

We are a layer

[Ilia Mirkin]

The (function() { ... })() construct avoids any variables leaking out
of the namespace created by the wrapper. You can still obviously
access window.foo, and IIRC some bits of closure library do that for
id's, so if you use those, you're sunk.

On Mon, Apr 18, 2016 at 10:05 AM, Marco Gadaleta

[Marco Gadaleta]

I use it in this way:

    "output-wrapper":"(function(){%output%})();",

but in the compiled js I've this kind of error

goog.debug.Error

You received this message because you are subscribed to a topic in the Google Groups "plovr" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/plovr/jZXyzdDqoxY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to plovr+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Marco Gadaleta

LinkedIn - Phone: 3479581185

In the meantime, stay curious, ambitious, daring, and above all, stay adventurous!

[Nick Santos]

I think you need to provide more context on what you're trying to do.
Maybe share your plovr configs?

On Mon, Apr 18, 2016 at 10:51 AM, Marco Gadaleta

[Marco Gadaleta]

Sure,

i add the attachments

[Andre Tannus]

I think I've ran into this before. I'm speaking from memory, so I may be wrong.

Does it work when you use a compile mode other than WHITESPACE? (Like RAW).

[Marco Gadaleta]

The compilation works well.

I think that could be something in the code that break the complied file (but i've no error during compilation).

So thanks for the help and i try to understand where is the problem in the code.

[Andre Tannus]

It should not break when compiled, only in WHITESPACE.

I think I mentioned it in this forum a while back.

[Andre Tannus]

This is the thread: https://groups.google.com/forum/#!searchin/plovr/plovr$20WHITESPACE/plovr/CU1RmOsX1tw/u6NctNBj1VoJ

[Marco Gadaleta]

It's the same problem

[Nick Santos]

I don't think it's possible to accomplish what you're trying to do.
The solution that you're trying (load closure-library twice on the
same page without compilation) is not supported by closure-library.
You have two options:

1) Compile both versions with SIMPLE or ADVANCED, and create an output
wrapper around each.
2) Use the closure-library code-loader (goog.require) to load both,
and let it de-dupe the common dependencies.

If you have questions about this, you're probably better off asking on
the closure-library-discuss mailing list.

On Tue, Apr 19, 2016 at 8:57 AM, Marco Gadaleta