I assume by "commercial project" you mean that you do not wish to disclose the source code for the product you are developing. Please correct me if my understanding is incorrect, as it is the basis of this answer.
I am not a lawyer, and this is not legal advice.
The LGPL 2.1, which appears to be the license of TinyMCE, is actually more permissive than the GPL. The LGPL 2.1 allows you to dynamically link against a shared library, and still keep the source code of your product "private" (closed source). Dynamic linking, in this case, would mean that you have a separate binary library that is TinyMCE (DLL for Windows or a .so file for Linux) that you ship to the end user of your product. TinyMCE and your "commercial project" cannot be combined into a single binary, unless you also intend to license your code under the LPL2.1. Your executable (which would be different binary from the TinyMCE binary) would then load this shared library at runtime in order to access the functionality of TinyMCE. You are NOT allowed to statically link against TinyMCE (i.e. build the functionality of TinyMCE directly into your application binary file) at build time and still keep your commercial project closed source.
The wrapper methodology that you describe is more applicable to the GPL (which does NOT appear to be the license of the library you are describing), where both static and dynamic linking require that your application MUST also be licensed under the GPL. If the library that you wish to use is licensed under the GPL, then you may choose to create a wrapper executable. Your closed source program should be able to send this "wrapper executable" data via the command line, sockets, or pipes.
From https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#MereAggregation :
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
If you end up distributing a binary that is licensed under the LGPL 2.1 (which is the case for TinyMCE), then you must abide by ALL of the requirements of the LGPL 2.1. This would include providing the source code for TinyMCE. It does not require you to release the source for any other programs where are dynamically linking against TinyMCE. If you do not send a TinyMCE binary to the end user (e.g. they download the TinyMCE library from some other third party on the internet), then you are not required to provide the source for it.
Edit: Update to include information that you still must release the source code for TinyMCE, if you send TinyMCE to an end user in binary format.